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Security Mechanisms 


Abstract 


This document shows example call flows demonstrating the use of 
Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail 
Extensions (S/MIME) in Session Initiation Protocol (SIP). It also 
provides information that helps implementers build interoperable SIP 
software. To help facilitate interoperability testing, it includes 
certificates used in the example call flows and processes to create 
certificates for testing. 
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This document is not an Internet Standards Track specification; it is 
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(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 
approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 
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and how to provide feedback on it may be obtained at 
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l; 


Introduction 


This document is informational and is not normative on any aspect of 
SIP. 


SIP with TLS ([RFC5246]) implementations are becoming very common. 
Several implementations of the S/MIME ([RFC5751]) portion of SIP 
([RFC3261]) are also becoming available. After several 


interoperability events, it is clear that it is difficult to write 
these systems without any test vectors or examples of "known good" 
messages to test against. Furthermore, testing at the events is 
often hindered due to the lack of a commonly trusted certification 
authority to sign the certificates used in the events. This document 
addresses both of these issues by providing messages that give 
detailed examples that implementers can use for comparison and that 
can also be used for testing. In addition, this document provides a 
common certificate and private key that can be used to set up a mock 
Certification Authority (CA) that can be used during the SIP 
interoperability events. Certificate requests from the users will be 
signed by the private key of the mock CA. The document also provides 
some hints and clarifications for implementers. 


A simple SIP call flow using SIPS URIs and TLS is shown in Section 3. 
The certificates for the hosts used are shown in Section 2.2, and the 
CA certificates used to sign these are shown in Section 2.1. 


The text from Section 4.1 through Section 4.3 shows some simple SIP 
call flows using S/MIME to sign and encrypt the body of the message. 
The user certificates used in these examples are shown in 

Section 2.3. These host certificates are signed with the same mock 
CA private key. 


Section 5 presents a partial list of items that implementers should 
consider in order to implement systems that will interoperate. 


Scripts and instructions to make certificates that can be used for 
interoperability testing are presented in Appendix A, along with 
methods for converting these to various formats. The certificates 
used while creating the examples and test messages in this document 
are made available in Appendix B. 


Binary copies of various messages in this document that can be used 
for testing appear in Appendix C. 
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2. Certificates 
2.1. CA Certificates 


The certificate used by the CA to sign the other certificates is 
shown below. This is an X.509v3 ([X.509]) certificate. Note that 
the X.509v3 Basic Constraints in the certificate allows it to be used 
as a CA, certification authority. This certificate is not used 
directly in the TLS call flow; it is used only to verify user and 
host certificates. 


Version: 3 (0x2) 
Serial Number: 
96:a3:84:17:4e:ef:8a:4c 
Signature Algorithm: shalWithRSAEncryption 
Issuer: C-US, ST-California, L-San Jose, O-sipit, 
OU-Sipit Test Certificate Authority 
Validity 
Not Before: Jan 27 18:36:05 2011 GMT 
Not After : Jan 3 18:36:05 2111 GMT 
Subject: C=US, ST=California, L-San Jose, O=sipit, 
OU-Sipit Test Certificate Authority 
Subject Public Key Info: 
Public Key Algorithm: rsaEncryption 
RSA Public Key: (2048 bit) 

Modulus (2048 bit): 
OO:ab:1f:91:61:f1:lc:c5:cd:a6:7b:16:9b:b7:14: 
79:e4:30:9e:98:d0:ec:07:b7:bd:77:d7:d1:f£5:5b: 
2c:e2:ee:e6:b1:b0:f0:85:fa:a5:be:cb:cc:cf:69: 
2c:4f£:fc:50:ef:9d:31:2b:c0:59:ea: fb: 64: 6f:1f: 
55:a7:3d:fd:70:d2:56:db:14:99:17:92:70:ac:26: 
£8:34:41:70:d9:c0:03:91:6a:ba:d1:11:8f:ac:12: 
31:de:b9:19:70:8d:5d:a7:7d:8b:19:cc:40:3f:ae: 
ff:de:1f:db:94:b3:46:77:6c:ae:ae:ff:3e:d6: 84: 
5b:c2:de:0b:26:65:Ad0:91:c7:70:4b:c7:0a:4a:bf: 
c7:97:04:dd:ba:58:47:cb:e0:2b:23:76:87:65:ca5: 
55:34:10:ab:27:1f:1c:f8:30:3d:b0:9b:ca:a2:81: 
72:4c:bd:60:fe:£7:21:fe:0b:db:0b:db:e9:5b:01: 
36:d4:28:15:6b:79:eb:d0:91:1b:21:59:b8:0e:aa: 
bf:d5:bl:6c:70:37:a3:3f:a5:7d:0e:95:46:f6: f6: 
58:67:83:75:42:37:18:0b:a4:41:39:b2:2f:6c:80: 
2c:78:eca:a5:0f:be:9c:10:f8:c0:0b:0d:73:99:9e: 
Od:d7:97:50:cb:cc:45:34:23:49:41:85:22:24:ad: 
ZILE 

Exponent: 65537 (0x10001) 

X509v3 extensions: 
X509v3 Subject Key Identifier: 
95:45: 7E:5F:2B:EA: 65: 98:12:91:04:F3:63:C7:68:9A:58:16:77:27 
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X509v3 Authority Key Identifier: 
95:45: 7E:5F:2B:EA: 65: 98:12:91:04:F3:63:C7:68:9A:58:16:77:27 


X509v3 Basic Constraints: 
CA: TRUE 

Signature Algorithm: shalWithRSAEncryption 
O6:5f:9e:ae:a0:9a:bc:b5:b9:5b:7e:97:33:cc:df:63:98:98: 
J4:cb:0d:66:a9:83:e8:aa:58:2a:59:al:9e:47:31:ab:af:5c: 
3fra2:25:86:f8:df:05:92:b7:db:69:al:69:72:87:66:c5:ab: 
35:89:01:37:19:c9:74:eb:09:d1:3f :88:7b:24:13:42:ca:2d: 
fb:45:e6:cc:4b:f8:21:78:f3:f5:97:ec:09:92:24:a2:f0:es6: 
94:8d:97:4a:00:94:00:bd:25:b8:17:2ca:52:53:5d:cc:5c:48: 
a4:al:ld:2d:f6:50:55:13:a4:d3:b2:a2:f4:f1:b9:6d:48:5e: 
Sc:f3:de:e0l0:fcec:59:09:al:d9:14:61:65:bf:d8:3f:b9:ba:2e: 
Tcred:5c:24:9b:6b:casaa:5f:fl:acl:le:b0:a8:da:82:0f: fb: 
4c:71:3b:4d:7b:38:c8:e3:8a:2a:19:34:44:26:0b:ea: f0:47: 
38:46:28:65:04:e2:01:52:dd:ec:3d:e5:£5:53:74:77:74:75: 
6d:c6:d9:c2:0a:ac:3b:b8: 98:5c:55:53:34:74:52:a8:26:b1: 
2£:30:22:d0:8b:b7:£3:a0:dd:68:07:33:d5:ae:b7:81:b2:94: 
58:72:4e:7ce:c6:72:2f:bd:6c:69:fb:b5:17:a8:2a:8d:d7:2c: 
91:06:c8:0c 


The certificate content shown above and throughout this document was 
rendered by the OpenSSL "x509" tool. These dumps are included only 
as informative examples. Output may vary among future revisions of 
the tool. At the time of this document’s publication, there were 
some irregularities in the presentation of Distinguished Names (DNs). 
In particular, note that in the "Issuer" and "Subject" fields, it 
appears the intent is to present DNs in Lightweight Directory Access 
Protocol (LDAP) format. If this was intended, the spaces should have 
been omitted after the delimiting commas, and the elements should 
have been presented in order of most-specific to least-specific. 
Please refer to Appendix A of [RFC4514]. Using the "Issuer" DN from 
above as an example and following guidelines in [RFC4514], it should 
have instead appeared as: 


Issuer: OU-Sipit Test Certificate Authority,O-sipit,L-San Jose, 
ST=California, C=US 


The ASN.1 ([X.683]) parse of the CA certificate is shown below. 


0:12 949 cons: SEQUENCE 
4:1= 669 cons: SEQUENCE 


8:1= 3 cons: cont [ 0 ] 

10:1- 1 prim: INTEGER :02 

13:1= 9 prim: INTEGER :96A384174EEF8A4C 
24:1= 13 cons: SEQUENCE 
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26:1= 9 
37:1= 0 
39:1= 112 
41:1= 11 
43:1= 9 
45:1= 3 
50:1= 2 
54:1= 19 
56:1= 17 
58:1- 3 
63:1= 10 

43 61 6c 
eee. d 
77:1= 15 
79:1= 3 
84:1= 8 

53 61 6e 
94:1= 14 
96:1= 12 
98:1= 3 

103:1= 5 

73 69 70 

110:1= 41 

112:1= 39 

114:1= 3 

119:1= 32 

53 69 70 

66 69 63 

153:1- 32 

155:1= 13 

170:1= 15 

187:1= 112 

189:1= 11 

191:1= 9 

193:1= 3 

198:1= 2 

202:1= 19 

204:1= 17 

206:1= 3 

211:1= 10 

43 61 6c 

223:1= 17 

225:1= 15 

227:1= 3 

232:1= 8 

53 61 6e 

242:1= 14 

244:1= 12 
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prim: OBJECT 

prim: NULL 

cons: SEQUENCE 

cons: SET 

cons: SEQUENCE 

prim: OBJECT 

prim: PRINTABLESTRING 
cons: SET 

cons: SEQUENCE 

prim: OBJECT 

prim: UTF8STRING 

69 66 6f 72 6e-69 61 
cons: SET 

cons: SEQUENCE 

prim: OBJECT 

prim: UTF8STRING 

20 4a 6f 73 65- 

cons: SET 

cons: SEQUENCE 

prim: OBJECT 

prim: UTF8STRING 

69 74 

cons: SET 

cons: SEQUENCE 

prim: OBJECT 

prim: UTF8STRING 

69 74 20 54 65-73 74 20 43 65 72 74 69 
61 74 65 20 41-75 74 68 6f 72 69 74 79 
cons: SEQUENCE 

prim: UTCTIME 

prim: GENERALIZEDTIME 
cons: SEQUENCE 

cons: SET 

cons: SEQUENCE 

prim: OBJECT 

prim: PRINTABLESTRING 
cons: SET 

cons: SEQUENCE 

prim: OBJECT 

prim: UTF8STRING 

69 66 6f 72 6e-69 61 
cons: SET 

cons: SEQUENCE 

prim: OBJECT 

prim: UTF8STRING 

20 4a 6f 73 65- 

cons: SET 

cons: SEQUENCE 
et al. 


:shalWithRSAEncryption 


:countryName 


: US 


:stateOrProvinceName 


California 


:localityName 


San Jose 


:organizationName 


sipit 


:organizationalUnitName 


:1101271836052 
:211101031836052 


:countryName 
:US 


:stateOrProvinceName 


California 


:localityName 


San Jose 


Informational 


April 2011 


Sipit Test Certi 
ficate Authority 


RFC 6216 


246:1= 3 prim: 
251:1= a pram: 
73 69 70 69 74 
258:1= 41 cons: 
260:1= 39 cons: 
262:1= 3 prim: 
267:1= 32 prim: 
53 69 70 69 74 
66 69 63 61 74 
301:1= 290 cons: 
305:1= 13 cons: 
307:1= 9 prim: 
318:1= 0 prim: 
320:1= 271 prim: 
00 30 82 01 Oa 
c5 cd a6 7b 16 
b7 bd 77 d7 di 
ab bc cb cc cf 
ea fb 64 6f 1f 
92 70 ac 26 f8 
8f ac 12 31 de 
3f ae ff de 1f 
84 5b c2 de Ob 
c7 97 04 dd ba 
34 10 ab 27 1f 
bd 60 fe f7 21 
15 6b 79 eb dO 
70 37 a3 3f a5 
37 18 0b a4 41 
9c 10 f8 cO Ob 


34 23 49 41 85 
595:1- 80 cons: 
597:1= 78 cons: 
599:1- 29 cons: 
601:1= 3 prim: 
606:1- 22 prim: 


04 14 95 45 7e 
68 9a 58 16 77 
630:l= 31 cons: 
632:1= 3 prim: 
637:1= 24 prim: 
30 16 80 14 95 
63 c7 68 9a 58 
663:l= 12 cons: 
665:1- 3 prim: 
670:1- 5 prim: 
30 03 01 01 ff 
677:1= 13 cons: 
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SE 


SEQUENCE 
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OBJECT 


UTF8STRING 


T 


OBJECT 


UTF8STRING 


20 54 65-73 74 20 
65 20 41-75 74 68 


02 
9b 
f9 
69 
55 
34 
b9 
db 
26 
58 
Je 
fe 
91 
7d 
39 
Od 
22 


2:7 


SEQ 
SE 
[e] 
N 


82 
57 
5b 
2c 
a7 
EN 
1:9 
94 
65 
47 
£8 
Ob 
1b 
0e 
b2 
73 
24 
con 
SE 


SEQUENCE 


SEQUENCE 


SEQUENCE 


UENCE 
QUENCE 
BJECT 
ULL 


01-01 
14-79 
2c-e2 
4f-fc 
3d-fd 
70-d9 
70-8d 
b3-46 
d0-91 
cb-e0 
30-3d 
db-Ob 
21-59 
95-46 
2f-6c 
99-9e 
ad-29 


t P 3x] 


QUENCE 


OBJECT 


BIT STRING 


00 
e4 
ee 
50 
70 
cO 
5d 
77 
e 
2b 
bo 
db 
b8 
f6 
80 
Od 
c3 


ab 
30 
e6 
ef 
d2 
03 
a7 
6c 
70 
23 
9b 
ER 
Oe 
£6 
2c 
d7 
02 


OCTET STRING 
5f 2b ea-65 98 12 


OBJECT 


OCTET STRING 
45 7e 5f-2b ea 65 
16 77 27- 


OBJECT 


OCTET STRING 


SEQUENCE 


43 
6f 


1f 
9e 
bl 
9d 
56 
91 
7d 
ae 
4b 
76 
ca 
5b 
aa 
58 
78 
97 
03 


91 


98 


65 
72 
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:organizationName 


sipit 


:organizationalUnitName 


72 74 69 Sipit Test Certi 
69 74 79 ficate Authority 


:rsaEncryption 


91 
98 
bo 
31 
db 
6a 
8b 
ae 
c7 
87 
a2 
01 
bf 
67 
ec 
50 
01 


04 


12 


61 f1 1c Su En NI or. EE 
dO ec 07 Este neces asl s sua sos 
f0 85 fa sw Wess uri shave co 
Zb "el 59. i i,0.P..1+.Y 
14 99 17 È 
ba di 11 PV AP DEE 
19 cc 40 EE Des alee eun 
ff 3e dé cubre Fwl...>. 
Oa 4a bf DR SE WO pK Ja 
B-C. WE 3v. XG..+#v.e.U 
81 72 4c 4. pew OF Lis rL 
36 d4 28 Ms DEEG [.6. ( 
d5 bi 6c 2 toric tl eno as 1 
83 75 42 p/.?.)..F..Xg.uB 
a5 Of be Ws est NO: lis 
CDY.GC.45 uuu iA. Ss ds P..E 
00 01 EFTA SH.) kwe ves 


:X509v3 Subject Key Identifier 


f3.63 e? DUDEN PA Ga 
h.X.w' 


:X509v3 Authority Key Identifier 


91 04 f3 0....F _+.e..... 
c.h.X.w’ 


:X509v3 Basic Constraints 


O.... 
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679:1= 
690:1= 
692:1= 257 


00 
63 
47 
al 
dl 
78 
94 
2d 
£3 
2e 
82 
26 
e5 
5G 
a0 
72 
Oc 


242. 


06 
98 
31 
69 
3f 
£3 
00 
f6 
de 
TE 
Of 
Ob 
£5 
55 
dd 
2f 


9 
0 


5f. 
98 
a6 
72 
88 
f5 
bd 
50 
e0 
ed 
fb 
ea 
53 
53 
68 
bd 


prim: 
prim: 
prim: 


9e 
94 
af 
87 
7b 
97 
25 
55 
fc 
5c 
4c 
£0 
74 
34 
07 
6c 


ae 
cb 
5c 
66 
24 
ec 
b8 
1:3 
59 
24 
71 
47 
77 
74 
33 
69 


OBJECT 


N 


ULL 


BIT STRING 
bc-b5 
a9-83 
25-86 
35-89 
ca-2d 
24-a2 
52-53 
b2-a2 
d9-14 
ca-aa 
75-38 
28-65 
6d-c6 
26-b1 
b7-81 
17-a8 


a0 
Od 
3f 
c5 
13 
09 
17 
a4 
09 
9b 
3b 
38 
74 
52 
d5 
fb 


9a 
66 
a2 
ab 
42 
92 
2c 
d3 
al 
6b 
4d 
46 
75 
a8 
ae 
b5 
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b9 
e8 
f8 
01 
fb 
£0 
5d 
£4 
61 
bif. 
c8 
04 
d9 
2f 
b2 
2a 


5b 
aa 
df 
37 
45 
e6 
cc 
Ft 
65 
f1 
e3 
e2 
c2 
30 
94 
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7e 
58 
05 
19 
e6 
94 
5c 
b9 
bf 
cl 
8a 
01 
Oa 
22 
58 
d7 


97 
2a 
92 
c9 
ec 
8d 
48 
6d 
d8 
le 
2a 
52 
ac 
do 
72 
2c 


33 
59 
b7 
74 
4b 
97 
a4 
48 
SE 
bo 
1:9 
dd 
3b 
8b 
4e 
91 


cc 
al 
db 
eb 
£8 
4a 
al 
5e 
b9 
a8 
34 
ec 
b8 
b7 
Te 
06 


df 
9e 
69 
09 
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00 
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5c 
ba 
da 
44 
3d 
98 
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The certificate for the host example.com is shown below. 
the Subject Alternative Name is set to example.com and is a DNS type. 
The certificates for the other hosts are shown in Appendix B. 


Version: 3 
Serial Number: 
I6:a3:84:17:4e:ef:8a:4f 
Signature Algorithm: 


(Ox 


2) 


shalWithRSAEncryption 
O=sipit, 


O=sipit, 


Issuer: C=US, ST=California, L=San Jose, 

OU-Sipit Test Certificate Authority 

Validity 
Not Before: Feb 7 19:32:17 2011 GMT 
Not After Jan 14 19:32:17 2111 GMT 
Subject: C=US, ST=California, L=San Jose, 
Subject Public Key Info: 
Public Key Algorithm: rsaEncryption 
RSA Public Key: (2048 bit) 

Modulus (2048 bit): 
00:dd:74:06:02:10:c2:e7:04:1f: 
9b:94:a3:48:37:85:9e:6d:83:12 
bl:fa:86:8c:a7:80:b9:be:52:ec: 
ad:f6:74:85:82:16:7e:4e:36:40: 
6a:0e:6a:7£:35:c£:70:71:63:7d: 
ea:b5:1e:b7:4c:a3:35:08:7b:21 
9d:8d:75:bf:1f£:d4:8e:e6:67:60: 
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be: 
: 84: 
a6: 
Oa: 
e9: 
STZ 
75: 


74 


f7 


8c: 
50: 
ca: 


43: 
2a: 


b6: 
la: 
63: 
$202 
67: 
73: 
:ea: 


CN=example.com 


24 
8e: 
47: 
20 
81: 
07: 
0a: 


:e7: 


48: 
84: 


:a9: 


Ac: 
63: 
7a: 
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6c:90:af:92:45:e0:62:05:9a:8a:10:98:dce:7c:54: 
8b:e4:61:95:3b:04:fc:10:50:ef:80:45:ba:5e: 84: 
97:76:c1:20:25:c1:92:1d:89:0a:£7:55:62:64:fa: 
e8:69:a2:62:4c:67:d3:08:d9:61:b5:3d:16:54:b6: 
b7:44:8d:59:2b:90:d4:e9:fb:c7:'7d:87:58:c3:12: 
ac:33:78:00:50:ba:07:05:b3:b9:01:1a:63:55:6c: 
el:7a:ec:a3:07:ae:3b:02:83:a1:69:e0:c3:dc:2d: 
61:e9:b2:e3:b3:71:c8:a6:cf:da:fb:3e:99:c7:e5: 
71:b9:0c9:17:d4:ed:bc:a0:47:54:09:8c:6e:6d:53: 
Ja:2c:c9:68:cC6:6f:f1:3d:91:la:24:43:77:7d:91: 
69:4b 
Exponent: 65537 (0x10001) 
X509v3 extensions: 
X509v3 Subject Alternative Name: 
DNS:example.com, URI:sip:example.com 
X509v3 Basic Constraints: 
CA:FALSE 
X509v3 Subject Key Identifier: 
CC:06:59:5B:8B:5E:D6:0D:F2:05:4D:1B:68:54:1E:FC:F9:43:19:17 
X509v3 Authority Key Identifier: 
95:45: 7E:5F:2B:EA:65:98:12:91:04:F3:63:C7:68:9A:58:16:77:27 


X509v3 Key Usage: 
Digital Signature, Non Repudiation, Key Encipherment 
X509v3 Extended Key Usage: 
TLS Web Server Authentication, 1.3.6.1.5.5.7.3.20 

Signature Algorithm: shalWithRSAEncryption 
6a:9a:dl:db:00:4b:90:86:b0:53:ea:6f:30:31:89:1e:9b:09: 
l4:bd:6f:b9:02:aa:6f:58:ee:30:03:b8:al:fd:b3:41:72:ff: 
b3:0d:cb:76:a7:17:c6:57:38:06:13:e5:f3:e4:30:17:4d: f7: 
I7:b5:f3:74:6e9:81:f8:f4:55:a3:0d:f5:82:38:c3:98:43:52: 
1f:84:cd:la:b4:a3:45:9f:3d:e2:31:fd:cb:a2:ad:ed:60:7d: 
fa:d2:aa:49:2f:41:a9:80:01:bb:ed:b6:75:09:97:69:7f£:0c: 
91:60:f£1:c4:5a:36:e8:5c:ac:el:a8:e7:9a:55:e5:e0:cd:01: 
f4iders93:£4:30:6€:0C01:71l:d2:fd:od:1b$50:2516b:90:7b::314 
41:e7:37:0e:e5:c0:01:48:91:f7:34:dd:c6:1f:74:e6:34:34: 
e6:cd:93:0f:3f:ce:94:ad:91:d9:e2:72:b1:9f:1d:d3:a5:7d: 
5e:e2:a4:56:c5:b1:71:4d:10:0a:5d:a6:56:e66:57:1£:48:a5: 
5c:75:67:ea:ab:35:3e:f6:b6:fa:c1:£3:8a:c1:80:71:32:18: 
6c:33:b5:fa:16:5a:16:el:al:6c:19:67:f5:45:68:64:6f:b2: 
31:dc:e3:5a:1a:b2:d4:87:89:96:fd:87:ba:38:4e:0a:19:07: 
03:4b:9b:b1 


The example host certificate above, as well as all the others 
presented in this document, are signed directly by a root CA. These 
certificate chains have a length equal to two: the root CA and the 
host certificate. Non-root CAs exist and may also sign certificates. 
The certificate chains presented by hosts with certificates signed by 


Jennings, et al. Informational [Page 9] 


RFC 6216 SIP Secure Call Flows April 2011 


non-root CAs will have a length greater than two. For more details 
on how certificate chains are validated, see Sections 6.1 and 6.2 of 
[RFC5280]. 


2.3. User Certificates 


User certificates are used by many applications to establish user 
identity. The user certificate for fluffy@example.com is shown 
below. Note that the Subject Alternative Name has a list of names 
with different URL types such as a sip, im, or pres URL. This is 
necessary for interoperating with a Common Profile for Instant 
Messaging (CPIM) gateway. In this example, example.com is the domain 
for fluffy. The message could be coming from any host in 
*.example.com, and the address-of-record (AOR) in the user 
certificate would still be the same. The others are shown in 
Appendix B.1. These certificates make use of the Extended Key Usage 
(EKU) extension discussed in [RFC5924]. Note that the X509v3 
Extended Key Usage attribute refers to the SIP OID introduced in 
[RFC5924], which is 1.3.6.1.5.5.7.3.20. 


Version: 3 (0x2) 
Serial Number: 
96:a3:84:17:4e:ef:8a:4d 
Signature Algorithm: shalWithRSAEncryption 
Issuer: C-US, ST-California, L=San Jose, O=sipit, 
OU-Sipit Test Certificate Authority 
Validity 
Not Before: Feb 7 19:32:17 2011 GMT 
Not After : Jan 14 19:32:17 2111 GMT 
Subject: C=US, ST=California, L-San Jose, O=sipit, 
CN-fluffy 
Subject Public Key Info: 
Public Key Algorithm: rsaEncryption 
RSA Public Key: (2048 bit) 

Modulus (2048 bit): 
O0:a3:2c:59:0c:e9:bc:e4:ec:d3:9e:fb:99:02:ec: 
b1:36:3a:b7:a3:ld:4d:c3:3a:b6:ae:50:bd:5f:55: 
08:77:8c:7e:a4:e9:£0:68:31:28:8£:23:32:56:19: 
C3:22:97:a7:6d:£d:a7:22:2a:01:Db5:af:61:bd:5f: 
Te:cl:14:e5:98:29:b4:34:4e:38:8a:26:ee:0d:da: 
db:27:b9:78:d6:ac:ac:04:78:32:98:c2:75:e7:6a: 
b7:2d:b3:3c:e3:eb:97:a5:ef:8b:59:42:50:17: 7b: 
fe:a7:8l:af:37:a7:e7:e3:1f£:b0:8d:d0:72:2f:6c: 
14:42:c6:01:68:e1:8£:£fd:56:4d:7d:cf:16:dc:aa: 
05:61:0b:Oa:ca:ca:ec:51:ec:53:6e:3d:2b:00:80: 
fe:35:1b:06:0a:61:13:88:0b:44:f£3:cc:fd:2b:0e: 
b4:a2:0b:a0:97:84:14:2e:ee:2b:e3:2f:cl:la:9e: 
86:9a:78:6a:a2:4c:57:93:e7:01:26:d3:56:0d: bd: 
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b0:2£:£8:da:c7:3c:01:dc: 
b4:63:e8:b2:a2:40:11:bf: 
47:f8:6a:15:8b:fb:27:96: 
cf:56:8d:d4:be:d6:94:5b: 
f2:d5 

onent: 65537 (0x10001) 


X509v3 extensions: 
X509v3 Subject Alternative Name: 


X509 


X509 


X509 


X509 


Signature Algorithm: 
a8:a9:8f: 
f2:2c:aa: 
:db: 
60:83:34: 
81:2f:46: 
f1:d7:54: 
83cerbls 
87:09:16: 


f0:be:77 


1520763 


aa:9e:b0: 
d6:65:86: 


1c:2e:f0 


09:68:63: 
6d:ab:0a: 
75:bf:6f: 


Versions 
included 
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URI 
v3 
CA: 
v3 
85: 
v3 
95: 


v3 
Dig 


e3 


50 


62 


09 


of 
in 


d8: 


d3: 
67: 
8d: 
ec: 
+ 2.5.5 


67: 
:b6: 
Q4: 
f8: 


:sip:fluffy@example.com, 


Basic Constraints: 
FALSE 
Subject Key Identifier: 


97:09:B8:D3:55:37:24:8A:DC:D 


Authority Key Identifier: 


cb: 
ad: 
73: 


£0 


Flows 


2d: 


31 


46 
67 


:8c: 
£8:6d:12: 
44: 
:a6: 


:34 
:e3 


6c:c6: 
01:97: 


id7:224.; 
dd: ef: 


April 2011 


5c: 
ld: 
Lex 
b4: 


URI:im:fluffyGexample.com, 
URI:pres:fluffyGexample.com 


E:E3:91:72:E4:22:CF:98:87:52 


45:7E:5F:2B:EA:65:98:12:91:04:F3:63:C7:68:9A:58:16:77:27 


Key Usage: 


ital Signature, Non Repudiation, 
X509v3 Extended Key Usage: 
E-mail Protection, 1.3.6.1.5.5.7.3.20 


8a:0b:88:ed:ff:4f:bf:e5 
:23:5b:9a:71:5e:tfd:20:a3: 
33:cc:8a:7b:4£:91:2b:8d: 
:bc:be:67:22:cd: £5:74:7b: 
Q9:9f:25:c3*20:68:102d5* 
D6:fl:l3:iCf:2f:fCt8b:834 
fO:c7:da:4e:bl:dc:cc:54 
af:af:el1:12:13:23:1e:0a: 
91:00:0e:90:db:d8:07:11: 
:0€3:36:f£0:0c:b7:2f:a7:17: 
73:74:6e:aa:3c:ee:47:38: 
04:7d:6c:38:db:81:9c:b8: 
6b:87:0e:36:b9:al:a3: fb: 
44:b0:78:19:1a:38:7e:fa: 


these certificates that 
Appendix B.2 


07 


c8: 
6a: 


do 


8f: 
ag: 
ET 
9a: 
388 


14 


6c: 


£5 


81: 
52: 
c8: 
:e3: 
30: 


al 


9e: 


a3 
14 
68 


7b: 
sen: 
3b: 
#65: 
01: 
36: 
6e: 


07 


0c: 
:d4: 


shalWithRSAEncryption 
sed: 
dd: 
d6: 
f4: 
ef: 
fe: 
TCE 
db: 
90: 
92: 
le: 


not make 


Informational 


7b: 
SOL 
FEI 
:a2: 
di: 
01: 
47: 
ff: 
3a: 
29: 
06: 
:be: 
a0: 
4b: 


b8:e6: 
f2:e8: 
8d:e0: 
52:2b: 
17:d4: 
922595 
47:59: 
5d:ab: 
48:a8: 
14:0a: 
81:85: 
FRIZE 
63:8d: 
4b:75: 


use of 


Key Encipherment 


EKU are also 
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3. Call Flow with Message Over TLS 
3.1. TLS with Server Authentication 


The flow below shows the edited SSLDump output of the host 
example.com forming a TLS [RFC5246] connection to example.net. In 
this example, mutual authentication is not used. Note that the 
client proposed three protocol suites including 

TLS RSA WITH AES 128 CBC SHA defined in [RFC5246]. The certificate 
returned by the server contains a Subject Alternative Name that is 
set to example.net. A detailed discussion of TLS can be found in SSL 
and TLS [EKR-TLS]. For more details on the SSLDump tool, see the 
SSLDump Manual [ssldump-manpage]. 


This example does not use the Server Extended Hello (see [RFC5246]). 


New TCP connection #1: example.com(50738) <-> example.net (5061) 
11 0.0004 (0.0004) C>SV3.1(101) Handshake 
ClientHello 
Version 3.1 
random[32]= 
4c 09 5b a7 66 77 eb 43 52 30 dd 98 4d 09 23 d3 
ff 81 74 ab 04 69 bb 79 8c dc 59 cd c2 1f b7 ec 
cipher suites 
TLS ECDHE RSA WITH AES 256 CBC SHA 
TLS ECDH RSA WITH AES 256 CBC SHA 


TLS DHE RSA WITH AES 256 SHA 

TLS RSA WITH AES 256 CBC SHA 

TLS DSS RSA WITH AES 256 SHA 

TLS ECDHE RSA WITH AES 128 CBC SHA 
TLS ECDH RSA WITH AES 128 CBC SHA 
TLS DHE RSA WITH AES 128 CBC SHA 
TLS RSA WITH AES 128 CBC SHA 

TLS DHE DSS WITH AES 128 CBC SHA 
TLS ECDHE RSA WITH DES 192 CBC3 SHA 
TLS ECDH RSA WITH DES 192 CBC3 SHA 
TLS DHE RSA WITH 3DES EDE CBC SHA 
TLS RSA WITH 3DES EDE CBC SHA 

TLS DHE DSS WITH 3DES EDE CBC SHA 
TLS ECDHE RSA WITH RC4 128 SHA 

TLS ECDH RSA WITH RC4 128 SHA 


TLS RSA WITH RC4 128 SHA 

TLS RSA WITH RC4 128 MD5 

TLS DHE RSA WITH DES CBC SHA 

TLS DHE RSA EXPORT WITH DES40 CBC SHA 
TLS RSA WITH DES CBC SHA 

TLS RSA EXPORT WITH DES40 CBC SHA 

TLS DHE DSS WITH DES CBC SHA 
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TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA 
TLS_RSA_EXPORT_WITH_RC4_40_MD5 
compression methods 

NULL 
12 0.0012 (0.0007) S>CV3.1(48) Handshake 
ServerHello 
Version 3.1 
random[32]= 
4c 09 5b a7 30 87 74 c7 16 98 24 d5 af 35 17 a7 
ef c3 78 Oc 94 d4 94 d2 7b a6 3f 40 04 25 f6 eO 
session id[0]- 
cipherSuite TLS RSA WITH AES 256 CBC SHA 
compressionMethod NULL 
13 0.0012 (0.0000) S>CV3.1(1858) Handshake 
Certificate 
1 4 0.0012 (0.0000) S>CV3.1(14) Handshake 
CertificateRequest 
certificate_types rsa_sign 
certificate_types dss_sign 
certificate_types unknown value 
ServerHelloDone 
15 0.0043 (0.0031) C>SV3.1(7) Handshake 
Certificate 
16 0.0043 (0.0000) C>SV3.1(262) Handshake 
ClientKeyExchange 
1 7 0.0043 (0.0000) cC>SV3.1(1) ChangeCipherSpec 
18 0.0043 (0.0000) cC>SV3.1(48) Handshake 
19 0.0129 (0.0085) S>CV3.1(170) Handshake 
1 10 0.0129 (0.0000) S>CV3.1(1) ChangeCipherSpec 
1 11 0.0129 (0.0000) S>CV3.1(48) Handshake 
1 12 0.0134 (0.0005) C>SV3.1(32) application data 
1 13 0.0134 (0.0000) C>SV3.1(496) application data 
1 14 0.2150 (0.2016) S>CV3.1(32) application data 
1 15 0.2150 (0.0000) S>CV3.1(336) application data 
1 16 12.2304 (12.0154) S>CV3.1(32) Alert 
1 12.2310 (0.0005) S>C TCP FIN 
1 17 12.2321 (0.0011) C>SV3.1(32) Alert 
3.2. MESSAGE Transaction Over TLS 
Once the TLS session is set up, the following MESSAGE request (as 
defined in [RFC3428] is sent from fluffy@example.com to 
kumiko@example.net. Note that the URI has a SIPS URL and that the 
VIA indicates that TLS was used. In order to format this document, 
the <allOneLine> convention from [RFC4475] is used to break long 
lines. The actual message does not contain the line breaks contained 
within those tags. 
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MESSAGE sips:kumiko@example.net:5061 SIP/2.0 

<allOneLine> 

Via: SIP/2.0/TLS 192.0.2.2:15001; 
branch-z9hGA4bK-d8754z-c785a077a9a8451b-1---d8754z-; 
rport-50738 

«/allOneLine» 

Max-Forwards: 70 

To: <sips:kumiko@example.net:5061> 

From: <sips:fluffy@example.com:15001>;tag=1a93430b 

Call-ID: OTZmMDE2OWNLYTVJNDkzYZzBhMWRIMDU4NDEXxZmU4ZTO. 

CSeq: 4308 MESSAGE 

<allOneLine> 

Accept: multipart/signed, text/plain, application/pkcs7-mime, 

application/sdp, multipart/alternative 

«/allOneLine» 

Content-Type: text/plain 

Content-Length: 6 


Hello! 


When a User Agent (UA) goes to send a message to example.com, the UA 
can see if it already has a TLS connection to example.com and if it 
does, it may send the message over this connection. A UA should have 
some scheme for reusing connections as opening a new TLS connection 
for every message results in awful performance.  Implementers are 
encouraged to read [RFC5923] and [RFC3263]. 


The response is sent from example.net to example.com over the same 
TLS connection. It is shown below. 


SIP/2.0 200 OK 

«allOneLine» 

Via: SIP/2.0/TLS 192.0.2.2:15001; 
branch-z9hGA4bK-d8754z-c785a077a9a8451b-1---d8754z-; 
rport-50738 

«/allOneLine» 

To: <sips:kumiko@example.net:5061>; tag=0d075510 

From: <sips:fluffy@example.com:15001>;tag=1a93430b 

Call-ID: OTZmMDE2OWNIYTVjNDkzYzBhMWRIMDUANDExZmUA4ZTOQ. 

CSeq: 4308 MESSAGE 

Content-Length: 0 
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4. Call Flow with S/MIME-Secured Message 
4.1. MESSAGE Request with Signed Body 


Below is an example of a signed message. The values on the Content- 
Type line (multipart/signed) and on the Content-Disposition line have 
been broken across lines to fit on the page, but they are not broken 
across lines in actual implementations. 


MESSAGE sip:kumiko@example.net SIP/2.0 

«allOneLine» 

Via: SIP/2.0/TCP 192.0.2.2:15001; 
branch-z9hGA4bK-d8754z-3a922b6dc0f0ff37-1---d8754z-; 
rport-50739 

«/allOneLine» 

Max-Forwards: 70 

To: <sip:kumiko@example.net> 

From: <sip:fluffy@example.com>;tag=efébad5e 

Call-ID: N2NiZ2jI0NjRjNDQOMTY1NDRjNWNmMGUIMDA2MDRhYmI. 

CSeq: 8473 MESSAGE 

«allOneLine» 

Accept: multipart/signed, text/plain, application/pkcs7-mime, 

application/sdp, multipart/alternative 

«/allOneLine» 

«allOneLine» 

Content-Type: multipart/signed; boundary=3b515e121b43a911; 

micalg=shal;protocol="application/pkcs7-signature" 
</allOneLine> 

Content-Length: 774 


--3b515e121b43a911 
Content-Type: text/plain 
Content-Transfer-Encoding: binary 


Hello! 

—-3b515e121b43a911 

Content-Type: application/pkcs7-signature;name-smime.p7s 
«allOneLine» 


Content-Disposition: attachment;handling-required; 
filename-smime.p7s 

«/allOneLine» 

Content-Transfer-Encoding: binary 


kkk k k k k k k k k k k k k x x 


* BINARY BLOB 1 * 


kkk kk k k k k k k k k k k x x 


--3b515e121b43a911-- 
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It is important to note that the signature ("BINARY BLOB 1") is 
computed over the MIME headers and body, but excludes the multipart 
boundary lines. The value on the Message-body line ends with CRLF. 
The CRLF is included in the boundary and is not part of the signature 
computation. To be clear, the signature is computed over data 
starting with the "C" in the "Content-Type" and ending with the "!" 
in the "Hello!". 


Content-Type: text/plain 
Content-Transfer-Encoding: binary 


Hello! 


Following is the ASN.1 parsing of encrypted contents referred to 
above as "BINARY BLOB 1". Note that at address 30, the hash for the 
Signature is specified as SHA-1. Also note that the sender's 
certificate is not attached as it is optional in [RFC5652]. 


0 472: SEQUENCE { 


4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 
15 457: [0] ( 
19 453: SEQUENCE { 
23 1$ INTEGER 1 
26 ld SET { 
28 9: SEQUENCE { 
30 54 OBJECT IDENTIFIER shal (1 3 14 3 2 26) 
37 0: NULL 
: } 
: } 
39 daks SEQUENCE { 
41 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 
I } 
52 420: SET { 
56 416: SEQUENCE ( 
60 dis INTEGER 1 
63 125: SEQUENCE ( 
65 112: SEQUENCE ( 
67 1 14 SET ( 
69 9: SEQUENCE ( 
71 3: OBJECT IDENTIFIER countryName (2 5 4 6) 
76 28 PrintableString 'US' 
: } 
I } 
80 19: SET { 
82 1: SEQUENCE { 
84 3: OBJECT IDENTIFIER 
: stateOrProvinceName (2 5 4 8) 
89 10: UTF8String “California” 
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} 
: } 
101 di Ze SET { 


103 15: SEQUENCE ( 
105 KR OBJECT IDENTIFIER localityName (2 5 4 7) 
110 8: UTF8String ’San Jose’ 
: } 
: } 
120 14: SET { 
122 12:5 SEQUENCE ( 
124 3 OBJECT IDENTIFIER 
$ organizationName (2 5 4 10) 
129 5:3 UTF8String 'sipit' 
: } 
: } 
136 41: SET { 
138 39: SEQUENCE { 
140 33 OBJECT IDENTIFIER 
š organizationalUnitName (2 5 4 11) 
145 32: UTF8String 'Sipit Test Certificate 
Authority' 
} 
} 
: } 
179 9: INTEGER 00 96 A3 84 17 4E EF 8A 4D 
: } 
190 9: SEQUENCE ( 
192 54 OBJECT IDENTIFIER shal (13 14 3 2 26) 
199 0: NULL 
: } 
201 1-3: SEQUENCE ( 
203 9: OBJECT IDENTIFIER 
: rsaEncryption (1 2 840 113549 1 1 1) 
214 0: NULL 
: ) 
216 256: OCTET STRING 


74 4D 21 39 D6 E2 E2 2C 30 5A AA BC 4E 60 8D 69 
A7 E5 79 50 1A B1 7D 4A D3 C1 03 9F 19 7D A2 76 
97 B3 CE 30 CD 62 4B 96 20 35 DB C1 64 DY 33 92 
96 CD 28 03 98 6E 2C OC F6 8D 93 40 F2 88 DA 29 
AD OB C2 OE F9 D3 6A 95 2C 79 6E C2 3D 62 E6 54 
A9 1B AC 66 DB 16 B7 44 6C 03 1B 71 9C EE C9 EC 
4D 93 B1 CF F5 17 79 C5 C8 BA 2F A7 6C 4B DC CF 
62 A3 F3 IA 1B 24 E4 40 66 3C 4F 87 86 BF 09 6A 
7A 43 60 2B FC D8 3D 2B 57 17 CB 81 03 2A 56 69 
81 82 FA 78 DE D2 3A 2F FA A3 C5 EA 8B E8 OC 36 
1B BC DC FD 1B 8C 2E OF 01 AF D9 EI 04 OE 4E 50 
94 75 7C BD D9 OB DD AA FA 36 E3 EC E4 A5 35 46 
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BE A2 97 1D AD BA 44 54 3A ED 94 DA 76 4A 51 BA 
A4 7D 7A 62 BF 2A 2F F2 5C 5A FE CA E6 B9 DC 5D 
EA 26 F2 35 17 19 20 CE 97 96 4E 72 9C 72 FD 1F 
68 Cl 6A 5C 86 42 F2 ED F2 70 65 4C C7 44 C5 7C 


SHA-1 parameters may be omitted entirely, instead of being set to 
NULL, a 
parameters set to NULL. Below are the same contents signed with the 
same key, but omitting the NULL according to [RFC3370]. This is the 
preferred encoding. This is covered in greater detail in Section 5. 


0 468: 
4 
15 453: 
19 449: 
23 
26 
28 
30 
37 11 
39 
50 418 
54 414 
58 
61 125 
63 112 
65 Td 
67 
69 
74 
78 1.9.3 
80 17: 
82 
87 10: 
99 17: 
Jennings, 


9s 


1:3 


9: 
TS 
5 


s mentioned in [RFC3370]. The above dump of Blob 1 has SHA-1 


SEQUENCE ( 
OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 
[0] ( 
SEQUENCE ( 
INTEGER 1 
SET { 
SEQUENCE ( 
OBJECT IDENTIFIER shal (1 3 14 3 2 26) 
} 
} 
SEQUENCE ( 
OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 
} 
SET { 
SEQUENCE ( 
INTEGER 1 
SEQUENCE { 
SEQUENCE ( 
SET { 
SEQUENCE { 
OBJECT IDENTIFIER countryName (2 5 4 6) 
PrintableString 'US' 
} 
} 
SET { 
SEQUENCE { 
OBJECT IDENTIFIER 
stateOrProvinceName (2 5 4 8) 
UTF8String ’California’ 
} 
} 
SET { 
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101 15: SEQUENCE { 
103 3: OBJECT IDENTIFIER localityName (2 5 4 7) 
108 8: UTF8String 'San Jose’ 
: } 
E } 
118 14: SET { 
120 12:3 SEQUENCE ( 
122 SE OBJECT IDENTIFIER 
S organizationName (2 5 4 10) 
127 9 UTF8String 'sipit' 
: } 
: } 
134 41: SET { 
136 3.9% SEQUENCE { 
138 3: OBJECT IDENTIFIER 
š organizationalUnitName (2 5 4 11) 
143 32: UTF8String 'Sipit Test Certificate 
Authority’ 
} 
} 
: } 
177 9: INTEGER 00 96 A3 84 17 4F FF 8A 4D 
: ) 
188 Js SEQUENCE í 
190 5$ OBJECT IDENTIFIER shal (1 3 14 3 2 26) 
: } 
197 13* SEQUENCE { 
1.99 SE OBJECT IDENTIFIER 
: rsaEncryption (1 2 840 113549 1 1 1) 
210 0: NULL 
: } 
212 256: OCTET STRING 


74 4D 21 39 D6 E2 E2 2C 30 5A AA BC 4E 60 8D 69 
A7 E5 79 50 1A B1 7D 4A D3 C1 03 9F 19 7D A2 76 
97 B3 CE 30 CD 62 4B 96 20 35 DB C1 64 D9 33 92 
96 CD 28 03 98 6E 2C OC F6 8D 93 40 F2 88 DA 29 
AD OB C2 OE F9 D3 6A 95 2C 79 6E C2 3D 62 E6 54 
A9 1B AC 66 DB 16 B7 44 6C 03 1B 71 9C EE C9 EC 
4D 93 B1 CF F5 17 79 C5 C8 BA 2F A7 6C 4B DC CF 
62 A3 F3 IA 1B 24 E4 40 66 3C 4F 87 86 BF 09 6A 
7A 43 60 2B FC D8 3D 2B 57 17 CB 81 03 2A 56 69 
81 82 FA 78 DE D2 3A 2F FA A3 C5 EA 8B E8 OC 36 
1B BC DC FD 1B 8C 2E OF 01 AF D9 EI 04 OE 4E 50 
94 75 7C BD D9 OB DD AA FA 36 E3 EC E4 A5 35 46 
BE A2 97 1D AD BA 44 54 3A ED 94 DA 76 4A 51 BA 
A4 7D 7A 62 BF 2A 2F F2 5C 5A FE CA E6 B9 DC 5D 
EA 26 F2 35 17 19 20 CE 97 96 4E 72 9C 72 FD LP 
68 C1 6A 5C 86 42 F2 ED F2 70 65 4C C7 44 C5 7C 
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} 
4.2. MESSAGE Request with Encrypted Body 


Below is an example of an encrypted text/plain message that says 
"Hello!". The binary encrypted contents have been replaced with the 
block "BINARY BLOB 2". 


MESSAGE sip:kumiko@example.net SIP/2.0 
<allOneLine> 
Via: SIP/2.0/TCP 192.0.2.2:15001; 
branch=z 9hG4bK-d8754z-c276232b541dd527-1---d8754z-; 
rport=50741 
</allOneLine> 
Max-Forwards: 70 
To: <sip:kumiko@example.net> 
From: <sip:fluffy@example.com>;tag=7a2e3025 
Call-ID: MDYyMDhhODA3NWE2ZjEyY zAwOTZ1MjJExXNWI2ZWQwZGM. 
CSeq: 3260 MESSAGE 
«allOneLine» 
Accept: multipart/signed, text/plain, application/pkcs7-mime, 
application/sdp, multipart/alternative 
«/allOneLine» 
«allOneLine» 
Content-Disposition: attachment;handling-required; 
filename-smime.p7 
«/allOneLine» 
Content-Transfer-Encoding: binary 
«allOneLine» 
Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 
name=smime.p7m 
</allOneLine> 
Content-Length: 565 


kkk k k k k k k k k k kx k k x x 


* BINARY BLOB 2 * 


kkk ck k k k k k k k k k k k x x 


Following is the ASN.1 parsing of "BINARY BLOB 2". Note that at 
address 454, the encryption is set to aes128-CBC. 


0 561: SEQUENCE { 
4 9s OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) 
15 546: [0] ( 
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OBJECT IDENTIFIER countryName (2 5 4 6) 


PrintableString 'US' 
} 


{ 

QUENCE { 

OBJECT IDENTIFIER 
stateOrProvinceName (2 5 4 8) 

UTF8String “California” 

} 


( 
QUENCE { 


OBJECT IDENTIFIER localityName (2 5 4 7) 


UTF8String 'San Jose’ 
} 


{ 

QUENCE { 

OBJECT IDENTIFIER 
organizationName (2 5 4 10) 
UTF8String 'sipit' 

} 


SET { 
SEQUENCE { 
OBJECT IDENTIFIER 
organizationalUnitName (2 5 4 11) 
UTF8String 'Sipit Test Certificate 
Authority’ 
} 
} 
} 
INTEGER 00 96 A3 84 17 4E EF 8A 4E 
} 
SEQUENCE { 
OBJECT IDENTIFIER 
rsaEncryption (1 2 840 113549 1 1 1) 
NULL 
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179 256: OCTET STRING 
: B9 12 8F 32 AB 4A E2 38 C1 EO 53 69 88 D6 25 E7 
40 03 B1 DE 79 21 A3 E8 23 5A 1B CB FB 58 F4 97 
48 A7 C8 FO 3D DF 41 A3 5A 90 32 70 82 FA BO DE 
D8 94 7C 6C 2E 01 FE 33 BD 62 CB 07 4F 58 DE 6F 
EA 3F EF B4 FB 46 72 58 9A 88 AO 85 BC 23 D7 C8 
09 OB 90 8D 4A 5F 3F 96 7C AC D4 E2 19 E8 02 B6 
OE F3 OD F2 91 4A 67 A9 EE 51 6A 97 D7 86 6D EC 
78 6E C6 EO 83 7C El 00 1F 5A 40 59 60 OC D7 EB 
A3 FB 04 B3 C9 A5 EB 79 ED B3 56 F8 F6 51 B2 5E 
58 E2 D8 17 28 33 A6 B8 35 8C OE 14 7F 90 DO 7B 
03 00 6C 3D 81 29 F5 D7 E5 AC 75 5E EO FO DD E3 
3E B2 06 97 D6 49 AY CB 38 08 F1 84 05 F5 CO BC 
55 A6 D4 C9 D8 FD A4 AC 40 9F 9D 51 5B F7 3A C3 
C3 CD 3A E7 6D 21 05 DO 50 75 4F 14 D8 77 76 C6 
13 A6 48 12 7B 25 CC 22 5D 73 BD 40 E4 15 02 A2 
39 4A CB D9 55 08 A4 EE 4E 8A 5E BA C4 4A 46 9C 
) 


: } 
439 124: SEQUENCE { 


441 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 
452 29: SEQUENCE { 
454 ER OBJECT IDENTIFIER 
: aesI28-CBC (216 840 1 101 3 41 2) 
465 16: OCTET STRING 


CA 35 CA BD 1E 78 83 D9 20 6C 47 B9 9F DC 91 88 

: } 

483 80: [0] 

$ 1B AE 12 C4 0E 55 96 AB 99 CC 1C 7F B5 98 A4 BF 
D2 D8 7F 94 BB B5 38 05 59 F2 38 Al CD 29 75 17 
1D 63 1B OB BO 2D 88 06 7F 78 80 F3 5A 3E DC 35 
BF 22 1E 03 32 59 98 DA FD 81 5F D9 41 63 3A 18 
FD B5 84 14 01 46 OB 40 EB 56 29 86 47 8B D1 EE 


} 
4.3. MESSAGE Request with Encrypted and Signed Body 


In the example below, some of the header values have been split 
across multiple lines. Where the lines have been broken, the 
<allOneLine> convention has been used. This was only done to make it 
fit in the RFC format. Specifically, the application/pkcs7-mime 
Content-Type line is one line with no whitespace between the "mime;" 
and the "smime-type". The values are split across lines for 
formatting, but are not split in the real message. The binary 
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encrypted content has been replaced with "BINARY BLOB 3", and the 
binary signed content has been replaced with "BINARY BLOB 4". 


MESSAGE sip:kumiko@example.net SIP/2.0 
<allOneLine> 
Via: SIP/2.0/TCP 192.0.2.2:15001; 
branch=z9hG4bK-a8754z-97a26e59b7262b34-1---d8754z-=; 
rport=50742 
«/allOneLine» 
Max-Forwards: 70 
To: <sip:kumiko@example.net> 
From: <sip:fluffy@example.com>;tag=379f5b27 
Call-ID: MjYwMzdjYTY3YWRkYzgzMjUOMGI4MZC2Njk1YzJINZE. 
CSeq: 5449 MESSAGE 
«allOneLine» 
Accept: multipart/signed, text/plain, application/pkcs7-mime, 
application/sdp, multipart/alternative 
«/allOneLine» 
«allOneLine» 
Content-Type: multipart/signed; boundary=e8df6elce5d1e864; 
micalg=shal;protocol="application/pkcs7-signature" 
</allOneLine> 
Content-Length: 1455 


--e8df6elce5die864 

«allOneLine» 

Content-Type: application/pkcs7-mime; smime-type-enveloped-data; 
name=smime.p7m 

</allOneLine> 

<allOneLine> 

Content-Disposition: attachment; handling=required; 

filename-smime.p7 
«/allOneLine» 
Content-Transfer-Encoding: binary 


KKKKKKKKKKKKKKKKK 


* BINARY BLOB 3 * 


kkk k k k k k k k k k k k k x x 


--e8df6elce5d1e864 
Content-Type: application/pkcs7-signature;name=smime.p7s 
<allOneLine> 


Content-Disposition: attachment;handling=required; 
filename=smime.p7s 

</allOneLine> 

Content-Transfer-Encoding: binary 


kkk k k k k k k k k k k k k xk x 


* BINARY BLOB 4 * 
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--e8df6elce5dle864-- 
Below is the ASN.1 parsing of "BINARY BLOB 3". 
0 561: SEQUENCE { 
4 os OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) 
15 546: [0] { 
19 542: SEQUENCE { 
23 T INTEGER 0 
26 409: SET { 
30 405: SEQUENCE { 
34 1: INTEGER 0 
37 - 1253 SEQUENCE { 
39 112: SEQUENCE { 
41 11: SET í 
43 9: SEQUENCE í 
45 3: OBJECT IDENTIFIER countryName (2 5 4 6) 
50 2: PrintableString 'US' 
: } 
: } 
54 19: SET { 
56 17 SEQUENCE { 
58 EE OBJECT IDENTIFIER 
3 stateOrProvinceName (2 5 4 8) 
63 10: UTF8String ‘California’ 
: } 
: } 
75 TF: SET { 
77 15:3 SEQUENCE { 
79 3: OBJECT IDENTIFIER localityName (2 5 4 7) 
84 8: UTF8String 'San Jose’ 
: } 
$ ) 
94 14: SET { 
96 125 SEQUENCE { 
98 3% OBJECT IDENTIFIER 
š organizationName (2 5 4 10) 
103 5:3 UTF8String 'sipit' 
š } 
: } 
110 41: SET { 
1:12 39: SEQUENCE í 
114 ES OBJECT IDENTIFIER 
$ organizationalUnitName (2 5 4 11) 
119 32: UTF8String 'Sipit Test Certificate 
Authority' 
} 
Jennings, et al. Informational 
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} 
: } 
153 9: INTEGER 00 96 A3 84 17 4E EF 8A 4E 


: } 
164 d SEQUENCE { 
166 os OBJECT IDENTIFIER 
E rsaEncryption (1 2 840 113549 1 1 1) 
177 0: NULL 
: } 
179 256: OCTET STRING 


49 11 0B 11 52 A9 9D E3 AA FB 86 CB EB 12 CC 8E 
96 9D 85 3E 80 D2 7C C4 9B B7 81 4B B5 FA 13 80 
6A 6A B2 34 72 D8 CO 82 60 DA B3 43 F8 51 8C 32 
8B DD DO 76 6D 9C 46 73 C1 44 AO 10 FF 16 A4 83 
74 85 21 74 7D EO FD 42 CO 97 00 82 A2 80 81 22 
9C A2 82 OA 85 FO 68 EF 9A D7 6D 1D 24 2B A9 5E 
B3 9A AO 3E A7 D9 1D 1C D7 42 CB 6F A5 81 66 23 
28 00 7C 99 6A B6 03 3F 7E F6 48 EA 91 49 35 F1 
FD 40 54 5D AC F7 84 EA 3F 27 43 FD DE E2 10 DD 
63 C4 35 4A 13 63 OB 6D OD 9A D5 AB 72 39 69 8C 
65 4C 44 C4 A3 31 60 79 B9 A8 A3 Al 03 FD 41 25 
12 E5 F3 F8 47 CE 8C 42 D9 26 77 A5 57 AF 1A 95 
BF 05 A5 E9 47 F2 D1 AE DC 13 7E 1B 83 5C 8C C4 
1F 31 BC 59 E6 FD 6E 9A BO 91 EC 71 A6 TF 28 3E 
23 1B 40 E2 CO 60 CF 5E 5B 86 08 06 82 B4 B7 DB 
00 DD AC 3A 39 27 E2 7C 96 AD 8A E9 C3 B8 06 5E 
) 


: } 
439 124: SEQUENCE { 


441 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 
452 29% SEQUENCE ( 
454 9: OBJECT IDENTIFIER 
: aesI28-CBC (216 840 1 1013 4 1 2) 
465 165 OCTET STRING 


88 9B 13 75 A7 66 14 C3 CF CD C6 FF D2 91 5D AO 


483 80: [0] 
: 80 0B A3 B7 57 89 B4 F4 70 AE 1D 14 A9 35 DD F9 

1D 66 29 46 52 40 13 Fl 3B 4A 23 E5 EC AB F9 35 

A6 B6 A4 BE CO 02 31 06 19 C4 39 22 7D 10 4C OD 

F4 96 04 78 11 85 4E 7E E3 C3 BC B2 DF 55 17 79 

5F F2 4E E5 25 42 37 45 39 5D F6 DA 57 9A 4E OB 
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Below is the ASN.1 parsing of "BINARY BLOB 4". 


101 
103 
105 
110 


120 
122 
124 


129 


136 


472: 
9:3 
457: 


453: 
ks? 
ks 
9: 
5: 
O's 


173 


10: 


Jennings, 


SEQUENCE ( 
OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 
[0] ( 
SEQUENCE ( 
INTEGER 1 
SET { 
SEQUENCE { 
OBJECT IDENTIFIER shal (1 3 14 3 2 26) 
NULL 
} 
} 
SEQUENCE ( 
OBJECT IDENTIFIER data (1 2 840 113549 1 7 
} 
SET { 
SEQUENCE ( 
INTEGER 1 
SEQUENCE ( 
SEQUENCE ( 
SET { 
SEQUENCE { 
OBJECT IDENTIFIER countryName (2 
PrintableString 'US' 
} 
} 
SET { 
SEQUENCE ( 
OBJECT IDENTIFIER 
stateOrProvinceName (2 5 4 8) 
UTF8String ’California’ 
} 
š } 
174 SET ( 
15 SEQUENCE ( 
ES OBJECT IDENTIFIER localityName 
8: UTF8String 'San Jose’ 
: } 
: } 
14: SET { 
12: SEQUENCE ( 
SR: OBJECT IDENTIFIER 
S organizationName (2 5 4 10) 
5: UTF8String 'sipit' 
: } 
: ) 
41: SET ( 
et al. Informational 
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(2 5 4 11) 
Certificate 


8A 4D 


(1.3 14 3 2 26) 


A8 
97 
35 
26 
46 
FD 
E 3 
14 
A2 
EC 
4A 
7B 
B2 
0B 
D9 
24 
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138 3:94 SEQUENCE ( 
140 ES OBJECT IDENTIFIER 
š organizationalUnitName 
145 32: UTF8String 'Sipit Test 
Authority' 
} 
: } 
: } 
179 9: INTEGER 00 96 A3 84 17 4E EF 
: } 
190 9: SEQUENCE í 
192 21 OBJECT IDENTIFIER shal 
199 0: NULL 
: ) 
201 13: SEQUENCE í 
203 9: OBJECT IDENTIFIER 
: rsaEncryption (1 2 840 113549 1 1 
214 0 NULL 
: ) 
216 256: OCTET STRING 
$ 6E 51 AC 24 2E BA 7C Al EE 80 
E5 29 09 5F B2 AF AA 6F 91 D2 
FE Al 73 FC E5 57 4E C6 3B 67 
93 EE 67 63 77 1E 7A 82 BC 1E 
26 92 01 6A B7 5D FO CO 2C 51 
64 C6 11 CB OB 6B FD F3 6D 7C 
78 9E F4 1B Al 20 68 B9 DE D3 
2C 64 AB 27 52 BD 52 EC 27 88 
EA 48 DB 07 E9 9B 2E C8 BE 62 
02 4B D1 86 E9 DF 2E BD 93 39 
1A B9 A6 31 FC E7 91 1C DB 22 
28 A9 CD DE 4A 04 6A EO 86 90 
96 A0 25 61 C2 58 A2 28 E5 B3 
78 61 OD D8 3A A7 9F A3 B5 87 
E5 17 1C EB 82 55 AB CD 04 E7 
FE FD CC B7 DB 47 6F 77 85 9E 
} 
5. Observed Interoperability Issues 


This section describes some common interoperability problems. 


D4 64 5D 
5B AF CA 
78 1E 59 
75 0C A6 
36 44 E3 
2E 91 BB 
F7 14 9A 
C3 54 C7 
53 37 E8 
53 A0 7F 
94 B2 4E 
DB 7A 96 
51:.:06::9€ 
C2 A9 1A 
E8 B7 47 
El E4 7D 


These 


were observed by the authors at SIPit interoperability events. 
Implementers should be careful to verify that their systems do not 
introduce these common problems, 


Jennings, 
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and, 


when possible, 
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clients forgiving in what they receive. Implementations should take 
extra care to produce reasonable error messages when interacting with 
software that has these problems. 


Some SIP clients incorrectly only do SSLv3 and do not support TLS. 
See Section 26.2.1 of [RFC3261]. 


Many SIP clients were found to accept expired certificates with no 
warning or error. See Section 4.1.2.5 of [RFC5280]. 


When used with SIP, TLS and S/MIME provide the identity of the peer 
that a client is communicating with in the Subject Alternative Name 
in the certificate. The software checks that this name corresponds 
to the identity the server is trying to contact. Normative text 
describing path validation can be found in Section 7 of [RFC5922] and 
Section 6 of [RFC5280]. If a client is trying to set up a TLS 
connection to good.example.com and it gets a TLS connection set up 
with a server that presents a valid certificate but with the name 
evil.example.com, it will typically generate an error or warning of 
some type. Similarly with S/MIME, if a user is trying to communicate 
with sip:fluffy@example.com, one of the items in the Subject 
Alternate Name set in the certificate will need to match according to 
the certificate validation rules in Section 23 of [RFC3261] and 
Section 6 of [RFC5280]. 


Some implementations used binary MIME encodings while others used 
base64. It is advisable that implementations send only binary and 
are prepared to receive either. See Section 3.2 of [RFC5621]. 


In several places in this document, the messages contain the encoding 
for the SHA-1 digest algorithm identifier. The preferred form for 
encoding as set out in Section 2 of [RFC3370] is the form in which 
the optional AlgorithmIdentifier parameter field is omitted. 

However, [RFC3370] also says the recipients need to be able to 
receive the form in which the AlgorithmIdentifier parameter field is 
present and set to NULL. Examples of the form using NULL can be 
found in Section 4.2 of [RFC4134]. Receivers really do need to be 
able to receive the form that includes the NULL because the NULL 
form, while not preferred, is what was observed as being generated by 
most implementations.  Implementers should also note that if the 
algorithm is MD5 instead of SHA-1, then the form that omits the 
AlgorithmIdentifier parameters field is not allowed and the sender 
has to use the form where the NULL is included. 


The preferred encryption algorithm for S/MIME in SIP is AES as 
defined in [RFC3853]. 
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Observed S/MIME interoperability has been better when UAs did not 
attach the senders’ certificates. Attaching the certificates 
significantly increases the size of the messages, which should be 
considered when sending over UDP. Furthermore, the receiver cannot 
rely on the sender to always send the certificate, so it does not 
turn out to be useful in most situations. 


Please note that the certificate path validation algorithm described 
in Section 6 of [RFC5280] is a complex algorithm for which all of the 
details matter. There are numerous ways in which failing to 
precisely implement the algorithm as specified in Section 6 of 
[RFC5280] can create a security flaw, a simple example of which is 
the failure to check the expiration date that is already mentioned 
above. It is important for developers to ensure that this validation 
is performed and that the results are verified by their applications 
or any libraries that they use. 


6. Additional Test Scenarios 


This section provides a non-exhaustive list of tests that 
implementations should perform while developing systems that use 
S/MIME and TLS for SIP. 


Much of the required behavior for inspecting certificates when using 
S/MIME and TLS with SIP is currently underspecified. The non- 
normative recommendations in this document capture the current 
folklore around that required behavior, guided by both related 


normative works such as [RFC4474] (particularly, Section 13.4 Domain 
Names and Subordination) and informative works such as [RFC2818], 
Section 3.1. To summarize, test plans should: 


o For S/MIME secured bodies, ensure that the peer’s URI (address-of- 
record, as per [RFC3261], Section 23.3) appears in the 
subjectAltName of the peer's certificate as a 
uniformResourceIdentifier field. 


o For TLS, ensure that the peer's hostname appears as described in 
[RFC5922]. Also: 


* ensure an exact match in a dNSName entry in the subjectAltName 
if there are any dNSNames in the subjectAltName. Wildcard 
matching is not allowed against these dNSName entries. See 
Section 7.1 of [RFC5922]. 


* ensure that the most specific CommonName in the Subject field 


matches if there are no dNSName entries in the subjectAltName 
at all (which is not the same as there being no matching 
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dNSName entries). This match can be either exact, or against 
an entry that uses the wildcard matching character '*'. 


The peer's hostname is discovered from the initial DNS query in 
the server location process [RFC3263]. 


IP addresses can appear in subjectAltName ([RFC5280]) of the 
peer's certificate, e.g., "IP:192.168.0.1". Note that if IP 
addresses are used in subjectAltName, there are important 
ramifications regarding the use of Record-Route headers that also 
need to be considered. See Section 7.5 of [RFC5922]. Use of IP 
addresses instead of domain names is inadvisable. 


For each of these tests, an implementation will proceed past the 
verification point only if the certificate is "good".  S/MIME 
protected requests presenting bad certificate data will be rejected. 
S/MIME protected responses presenting bad certificate information 
will be ignored. TLS connections involving bad certificate data will 
not be completed. 


E. 


2. 


S/MIME : Good peer certificate 


S/MIME : Bad peer certificate (peer URI does not appear in 
subjectAltName) 


S/MIME : Bad peer certificate (valid authority chain does not 
end at a trusted CA) 


S/MIME : Bad peer certificate (incomplete authority chain) 


S/MIME : Bad peer certificate (the current time does not fall 
within the period of validity) 


S/MIME : Bad peer certificate (certificate, or certificate in 
authority chain, has been revoked) 


S/MIME : Bad peer certificate ("Digital Signature" is not 
Specified as an X509v3 Key Usage) 


TLS : Good peer certificate (hostname appears in dNSName in 
subjectAltName) 
TLS : Good peer certificate (no dNSNames in subjectAltName, 


hostname appears in Common Name (CN) of Subject) 
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10. TLS : Good peer certificate (CN of Subject empty, and 
subjectAltName extension contains an iPAddress stored in the 
octet string in network byte order form as specified in RFC 791 


[RFCO791]) 

11. TLS : Bad peer certificate (no match in dNSNames or in the 
Subject CN) 

12. TLS : Bad peer certificate (valid authority chain does not end 


at a trusted CA) 
13. TLS : Bad peer certificate (incomplete authority chain) 


14. TLS : Bad peer certificate (the current time does not fall 
within the period of validity) 


15. TLS : Bad peer certificate (certificate, or certificate in 
authority chain, has been revoked) 


16. TLS : Bad peer certificate ("TLS Web Server Authentication" is 
not specified as an X509v3 Key Usage) 


17. TLS : Bad peer certificate (Neither "SIP Domain" nor "Any 
Extended Key Usage" specified as an X509v3 Extended Key Usage, 
and X509v3 Extended Key Usage is present) 
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test scenario content. 


Jennings, et al. Informational [Page 31] 


RFC 6216 SIP Secure Call Flows April 2011 


8. Security Considerations 


Implementers must never use any of the certificates provided in this 
document in anything but a test environment. Installing the CA root 
certificates used in this document as a trusted root in operational 
software would completely destroy the security of the system while 
giving the user the impression that the system was operating 
securely. 


This document recommends some things that implementers might test or 
verify to improve the security of their implementations. It is 
impossible to make a comprehensive list of these, and this document 
only suggests some of the most common mistakes that have been seen at 
the SIPit interoperability events. Just because an implementation 
does everything this document recommends does not make it secure. 


This document does not show any messages to check certificate 
revocation status (see Sections 3.3 and 6.3 of [RFC5280]) as that is 
not part of the SIP call flow. The expectation is that revocation 
status is checked regularly to protect against the possibility of 
certificate compromise or repudiation. For more information on how 
certificate revocation status can be checked, see [RFC2560] (Online 
Certificate Status Protocol) and [RFC5055] (Server-Based Certificate 
Validation Protocol). 
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Appendix A. Making Test Certificates 


These scripts allow you to make certificates for test purposes. The 
certificates will all share a common CA root so that everyone running 
these scripts can have interoperable certificates. WARNING - these 
certificates are totally insecure and are for test purposes only. 

All the CAs created by this script share the same private key to 
facilitate interoperability testing, but this totally breaks the 
security since the private key of the CA is well known. 


The instructions assume a Unix-like environment with openssl 
installed, but openssl does work in Windows too. OpenSSL version 
0.9.8j was used to generate the certificates used in this document. 
Make sure you have openssl installed by trying to run "openssl". Run 
the makeCA script found in Appendix A.1; this creates a subdirectory 
called demoCA. If the makeCA script cannot find where your openssl 
is installed you will have to set an environment variable called 
OPENSSLDIR to whatever directory contains the file openssl.cnf. You 
can find this with a "locate openssl.cnf". You are now ready to make 
certificates. 


To create certificates for use with TLS, run the makeCert script 
found in Appendix A.2 with the fully qualified domain name of the 
proxy you are making the certificate for, e.g., "makeCert 
host.example.net domain eku". This will generate a private key and a 
certificate. The private key will be left in a file named 

domain key example.net.pem in Privacy Enhanced Mail (PEM) format. 
The certificate will be in domain cert example.net.pem. Some 
programs expect both the certificate and private key combined 
together in a Public-Key Cryptography Standards (PKCS) 412 format 
file. This is created by the script and left in a file named 
example.net.pl2. Some programs expect this file to have a .pfx 
extension instead of .pl2 -- just rename the file if needed. A file 
with a certificate signing request, called example.net.csr, is also 
created and can be used to get the certificate signed by another CA. 


A second argument indicating the number of days for which the 
certificate should be valid can be passed to the makeCert script. It 
is possible to make an expired certificate using the command 
"makeCert host.example.net 0". 


Anywhere that a password is used to protect a certificate, the 
password is set to the string "password". 


The root certificate for the CA is in the file 
root cert fluffyCA.pem. 
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For things that need DER format certificates, a certificate can be 
converted from PEM to DER with "openssl x509 -in cert.pem -inform PEM 
-out cert.der -outform DER". 


Some programs expect certificates in PKCS #7 format (with a file 
extension of .p7c). You can convert these from PEM format to PKCS #7 
with "openssl crl2pkcs7 -nocrl -certfile cert.pem -certfile demoCA/ 
cacert.pem -outform DER -out cert.plc". 


IE (version 8), Outlook Express (version 6), and Firefox (version 
3.5) can import and export .p12 files and .p7c files. You can 
convert a PKCS #7 certificate to PEM format with "openssl pkcs7 -in 
cert.p7c -inform DER -outform PEM -out cert.pem". 


The private key can be converted to PKCS #8 format with "openssl 
pkcs8 -in a key.pem -topk8 -outform DER -out a key.p8c". 


In general, a TLS client will just need the root certificate of the 
CA. A TLS server will need its private key and its certificate. 
These could be in two PEM files, a single file with both certificate 
and private key PEM sections, or a single .pl2 file. An S/MIME 
program will need its private key and certificate, the root 
certificate of the CA, and the certificate for every other user it 
communicates with. 


A.1. makeCA script 


#!/bin/sh 
set -x 


rm -rf demoCA 


mkdir demoCA 

mkdir demoCA/certs 

mkdir demoCA/crl 

mkdir demoCA/newcerts 

mkdir demoCA/private 

# This is done to generate the exact serial number used for the RFC 
echo "4902110184015C" » demoCA/serial 

touch demoCA/index.txt 


# You may need to modify this for where your default file is 

# you can find where yours in by typing "openssl ca" 

for D in /etc/ssl /usr/local/ssl /sw/etc/ssl /sw/share/ssl; do 
CONF-S$(OPENSSLDIR:-$D)/openssl.cnf 
[ -f S(CONF) ] 66 break 

done 
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CONF=S {OPENSSLDIR}/openssl.cnf 


if [ ! -f SCONF J]; then 
echo "Can not find file $CONF - set your OPENSSLDIR variable" 
exit 

fi: 


cp SCONF openssl.cnf 


cat >> openssl.cnf  ««EOF 

[ sipdomain cert ] 

subjectAltName=\$ {ENV: : ALTNAME } 

basicConstraints=CA: FALSE 

subjectKeyIdentifier-hash 
authorityKeyIdentifier-keyid,issuer 

keyUsage = nonRepudiation,digitalSignature,keyEncipherment 
extendedKeyUsage=serverAuth,1.3.6.1.5.5.7.3.20 


[ sipdomain_req ] 
basicConstraints = CA:FALSE 
subjectAltName=\$ {ENV: : ALTNAME } 
subjectKeyIdentifier-hash 


[ sipuser cert ] 

subjectAltName=\$ {ENV: : ALTNAME) 

basicConstraints=CA: FALSE 

subjectKeyIdentifier-hash 
authorityKeyIdentifier-keyid,issuer 

keyUsage = nonRepudiation,digitalSignature,keyEncipherment 
extendedKeyUsage=emailProtection,1.3.6.1.5.5.7.3.20 


[ sipuser_req ] 
basicConstraints = CA:FALSE 
subjectAltName=\$ {ENV: : ALTNAME } 
subjectKeyIdentifier-hash 


[ sipdomain noeku cert ] 

subjectAltName=\$ (ENV: : ALTNAME } 

basicConstraints=CA: FALSE 

subjectKeyIdentifier-hash 
authorityKeyIdentifier-keyid,issuer 

keyUsage = nonRepudiation,digitalSignature,keyEncipherment 


[ sipdomain_noeku_req ] 
basicConstraints = CA:FALSE 
subjectAltName=\$ {ENV: : ALTNAME } 
subjectKeyIdentifier-hash 
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[ sipuser_noeku_cert ] 

subjectAltName=\$ {ENV: : ALTNAME } 

basicConstraints=CA: FALSE 

subjectKeyIdentifier-hash 
authorityKeyIdentifier-keyid,issuer 

keyUsage = nonRepudiation,digitalSignature,keyEncipherment 


[ sipuser_noeku_req ] 
basicConstraints = CA:FALSE 
subjectAltName=\$ {ENV: : ALTNAME } 
subjectKeyIdentifier-hash 


EOF 


cat » demoCA/private/cakey.pem ««EOF 


MIIFDjBABgkqhkiG9wOBBOOwMzAbBgkqhkiG9wOBBOwwDgOIlwtc771DlNUCAggA 
MBOGCCqGSIb3DOMHBAhRD3Z1i2TavwSCBMgXoXo0H/dTplHwnqfW7Uhldr776z7B 
ISNxlenMA61YmALF/4E1tq0E2 /aEbr8W3wTVjNpew9r5TBsbA11I9/FMMe+USclra 
5pIdDLx7ynzHvxcUWJ1xbWGeLcEmXGOvzkwW/oOg49YqlcelGtlLSV2L7Wi93TUQ 
Q81510X0xjx7cB7kaHTOTyaNOsxUE3ql1Q2sXTbbHWUfIaNpEZUI5DITrDUfl1fMnxb 
RogQGv45owsM7zwzfyGz3QocM9WaZwKFOEOqBvEfGaaZ9ml*tcnlRz/1Id7tSBlRH 
3ucN2mGdEVIUvzSACZ9LPulO7WBGMb56enDRsqZji4AWfqDHdXa4gkJKqPEJeBnLVA 
jxCmLJSyikM25kHDm8LWuOCkO/Rk-*7999h13Qvl1Ynm7yCincorqdlTrAdmq1Z8T 7 
QPgXioTIx6++6yxiDCVT7Mwkydox31K9y/T£2cZ2//dWuf / 1fMaaq8HfpSN14RKqsz 
uUfL41KS5SCZPRIUQUdoOoUQSGPCOJgcskPcifT6zvrI62KLPFVrwGSHT9P devQvcC60 
VgglxbEGJ714vllzmY62/0LtQKIA6bh8pszvvmHjGo9sctftp7KJVYygEHNEmRTm-* 
8M20wk67033sV6IClDOAdRL8siTHmcmM-4*rl1x9VVIppsDrzjqOqYVGYBbjEJW8eQp 
t7kAjuNA8tDD1mS8E6DstPv/6S0AjzAqCbjkuPJOWU5fDlcY*iTpo9vcunohcj-*i 
KVXsM34wOSBpMBjFQ-*Aww5bsIkEV1liOYLav1F7/BvP2s0gc3puM5W35ylcbKLu2 
ThJV7mIWoV770aQYpJba0OUAk9OzBVEvPNahrDIlNucbEkFrhN2pfnOs7k4UvrjiK 
uknKrm3gocDOdst yMZX8 1Bey j0 6NhpcJH+bOSvROk/d68aAsapy6qS 9hLi jNNbcd 
itQ/fo+1o9MDujT/huj7ZFqdzNM3KA 6vxfOkmmVM+GJbYke+cjXk 6NB801F91YcB 
OpWPd+fgwFL252FUoFcjvUWFXkvbR1+IMKkv6sNdKCXHHazAEG6n16yP1I9bVwCaS11I 
WNgETHntb1INZbeW+3qgH80v1ZXVCgEmaHka j SANFJKXCgpSXaIx2FSntzpVFbRpnw 
Yd9eml9xwgE3l9aRuvR6p6lfd051LzCh7KjvorV1CemPUT6YRBamFNCBoT7cqjh 
kqMOfowKkMEYOp2dzMnGzsSPKk10nI53RgPyD/8FT5dPuq073SyjxTKhAbvl-ctkVl 
lrfZ6b7P/UKwLBCT3bLG6uU/Es84euWN-U2JXIADPoCcVeWrUqkf4j368c2Z28Zdd 
A27XAZJtq*YfsFNiOA7vshHi3Am3gBzQhEEGsRdzgkf8gmtlRGhq/823GEexoUfu 
8Si0OOjoUO8HGAKTtPWjV5+0C6Q6RW9S9SmNMwz 7ms ZHoKTQ8kz2LKXUwb6DBwWcw6 / 
UTUgzVXqhA8HmjsnVe9ftDKL66v9zlp4RVRdDzm4TYUybYhb5uigFbjJFLlnJnJho 
TcnusHO80Cxgs64khLRzMA60i-*JSEPv70o7zHcfWNOVtNW908EKCubtEDZtnOn9VC 
OSky9R/WzunaLlG3LZ3BRUhWpyyvdNxlNq3ie4tcRMIXIEel4UZNOSsPCKZY//NEn 
BEc- 


ti 
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cat > demoCA/cacert.pem <<EOF 


MIIDt TCCAp2gAwIBAgIJAJajhBdO74pMMAOGCSqGSIb3DQEBBOUAMHAXCZAJBgNV 
BAYTA1VTMRMwEQYDVOQIDApDYWxpzm9ybm1lhMREwDwYDVOQHDAhHTYW4gSm9zZTEO 
MAWwGAIUECgwFc2lwaXOxKTAnBgNVBASMIFNpcGIOIFRIc3QgOQ2VydG1maWNhdGUg 
OQOXVO0aG9yaXR5MCAXDTExMDEyNzE4Mz YwNVOYDz IXMTEwMTAZMTgzNjA1WjBwMOsw 
CQYDVQQGEwJVUZETMBEGA1UECAwKO2F saWZvcm5pY TERMA8GA1UEBwwlU2FulEpv 
C2UxDjAMBgNVBAoMBXNpcGlOMSkwJwYDVOOLDCBTaXBpdCBUZXNOIENlcnRpZmlj 
YXRLIEF1dGhvcm10eTCCAS IwDQYJKoZIhvcNAQEBBOADgGgEPADCCAQoCggEBAKsf 
kWHxHMXNpnsWm7cUeeQwnpjQ7Ae3vXfXOfVbLOLu5rGw81lX6pbzLzM9pLE/8UO-*d 
MSvAWer7ZG8fVac9/XDSVt sUmReScKwm+DRBcNnAA5F qutER 7 6wSMd65GXCNXad9 
ixnMQD-*tu/94f25SzRndsrq7/PtaEW8LeCyZlOJHHcEvHCkq/x5cE3bpYR8vgKyN2 
h2XFVTOOqycfHPgwPbCbyqKBcky9YP731f4L2wvb6VsBNtOQOoFWt569CRGyFZuA6q 
v9WxbHA30z+1f£O6VRvb2WGeDdUI 3GAukOTmyL2yALH jspQ++nBD4wAsNc5meDdeX 
UMvMRTQjSUGFIiStKcMCAwEAAaNOMEAwHOQYDVROOBBYEFJVFfl8r6mWYEpEE82PH 
aJpYFncnMB8GA1UdIwQYMBaAFJVFfl8r6mWYEpEE82PHaJpYFncnMAwGAl1UdEwOQF 
MAMBAf8wDOYJKOZIhvcNAOEFBOADggEBAAZfnq6gmryluVt-lzPM320YmJTLDWap 
g+iqgWCpZoZ5HMaavXD+iJYb43wwSt 9tpoWwlyh2bFqzWJATCZVYXTrCdE/iHskEOLK 
LÉtF58xL+CF48/WX7AmMSJKLw5p SN1I106A1AC9JbgXLFJTXCxcSKSHHS32UFUTpNOy 
ovTxuWlIXlzz3uD8WQmh2RRhZb/YP7m6LnztXCSba8qqX/HBHrCo20IP-*0xx0017 
OMjjiioZNEQOmC-trwRzhGKGUEAgFS3ew95fVTdHdOdW3G2cIKrDu4mFxVUzROÜUqgm 
SS8wItCLt/Og3WgHMOWut 4GylFhyTnzGci+9bGn7tReoKo3XLJEGyYAw= 


# uncomment the following lines to generate your own key pair 


Sipit Test Certificate Authority 


# openssl req -newkey rsa:2048 -passin pass:password \ 

# -passout pass:password -set serial 0x96a384174eef8a4c \ 
# -shal -x509 -keyout demoCA/private/cakey.pem \ 

# -out demoCA/cacert.pem -days 36500 -config ${CONF} <<EOF 
# US 

# California 

# San Jose 

# sipit 

# 

# 

# 

# 


EOF 


# either randomly generate a serial number, or set it manually 
# hexdump -n 4 -e '4/1 "$04u"' /dev/random > demoCA/serial 
echo 96a384174eef8a4d » demoCA/serial 
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openssl crl2pkcs7 -nocrl -certfile demoCA/cacert.pem \ 
-outform DER -out demoCA/cacert.p7c 


cp demoCA/cacert.pem root_cert_fluffyCA.pem 


A.2. makeCert script 


#!/bin/sh 
set -x 
# Make a symbolic link to this file called "makeUserCert" 
# if you wish to use it to make certs for users. 
# ExecName-$ (basename $0) 
# 
# if [ S(ExecName) == "makeUserCert" ]; then 
# ExtPrefix="sipuser" 
# elif [ ${ExecName} == "makeEkuUserCert" ]; then 
# ExtPrefix="sipuser eku" 
# elif [ ${ExecName} == "makeEkuCert" ]; then 
# ExtPrefix="sipdomain eku" 
# else 
# ExtPrefix="sipdomain" 
# fi 
if [ $# == ]; then 
DAYS-36500 
elif [ $4 == 4 ]; then 
DAYS-$4 
else 
echo "Usage: makeCert test.example.org user|domain eku|noeku [days]" 
echo " makeCert alice@example.org [days]" 
echo "days is how long the certificate is valid" 
echo "days set to 0 generates an invalid certificate" 
exit 0 
fi 


ExtPrefix-"sip"$(2] 
if [ $3 -- "noeku" ]; then 
ExtPrefix-$(ExtPrefix)" noeku" 


fi 


DOMAIN-'echo $1 | perl -ne “(print "SINn" if (/(NwtN..*)$/)]*' 


` 


USER=`echo $1 | perl -ne “(print "$1\n" if (/(\w+)\@(\w+\..*)$/))" 


ADDR=$1 
echo "making cert for $DOMAIN S{ADDR}" 
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if [ $2 == "user" ]; then 
CNVALUE=SUSER 

else 
CNVALUE=SDOMAIN 

fi 


rm -f $(ADDR) *.pem 
rm -f ${ADDR}.p12 


case $(ADDR) in 

*:*) ALTNAME="URI:${ADDR}" ;; 

*@*) ALTNAME="URI:sip:${ADDR},URI:im:${ADDR},URI:pres:${ADDR}" ;; 
ka) ALTNAME="DNS:S{DOMAIN},URI:sip:${ADDR}" ;; 

esac 


rm -f demoCA/index.txt 
touch demoCA/index.txt 
rm -f demoCA/newcerts/* 


export ALTNAME 


openssl genrsa -out S{ADDR}_key.pem 2048 

openssl req -new -config openssl.cnf -reqexts S(ExtPrefix) req N 
-shal -key ${ADDR}_key.pem N 
-out ${ADDR}.csr -days S{DAYS} <<EOF 

US 

California 

San Jose 

sipit 


$ { CNVALUE } 


EOF 


if [ SDAYS == 0 ]; then 
openssl ca -extensions ${ExtPrefix}_cert -config openssl.cnf N 
-passin pass:password -policy policy anything \ 
-md shal -batch -notext -out ${ADDR}_cert.pem \ 
-startdate 9901010000002 \ 
-enddate 0001010000002 N 
-infiles ${ADDR}.csr 
else 
openssl ca -extensions ${ExtPrefix}_cert -config openssl.cnf N 
-passin pass:password -policy policy anything \ 
-md shal -days ${DAYS} -batch -notext -out ${ADDR}_cert.pem \ 
-infiles ${ADDR}.csr 
fi 
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openssl pkcs12 -passin pass:password N 
-passout pass:password -export \ 
-out ${ADDR}.p12 -in ${ADDR}_cert.pem N 
-inkey $(ADDR) key.pem -name $(ADDR) -certfile demoCA/cacert.pem 


openssl x509 -in ${ADDR}_cert.pem -noout -text 


case ${ADDR} in 
*@*) mv S(ADDR) key.pem user key S(ADDR).pem; N 
mv $(ADDR) cert.pem user cert S(ADDR).pem ;; 
Kal mv S{ADDR}_key.pem domain key S(ADDR).pem; N 
mv $(ADDR) cert.pem domain cert S(ADDR).pem ;; 
esac 


Appendix B. Certificates for Testing 


This section contains various certificates used for testing in PEM 
format. 


B.1. Certificates Using EKU 


These certificates make use of the EKU specification described in 
[RFC5924]. 
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MIIEGTCCAwGgAwIBAgIJAJajhBdO74pNMAO0GCSqGSIb3DQEBBQUAMHAxCZAJBgNV 
BAYTAIVTMRMwEQYDVOOIDApDYWxpZm9ybmlhMREwDwYDVOOHDAhTYW4gSm9zZTEO 
MAWwGAIUECgwFc2 lwaXQxKTAnBgNVBASMIFNpcG10IFR1c30gQ2VydGlmaWNhdGUg 
QOXV0aG9yaXRSMCAXDTEXMDIWNZESMzIxN1loYDzIxMTEWMTEOMTkzMjE3WjBWMQsw 
COYDVOQQGEWJVUZETMBEGA1UECBMKQ2F saWZvcm5pYTERMA8GA1UEBxMIU2FulEpv 
C2UxDjAMBgNVBAOTBXNpcGl0MQO8wDOYDVOODEwZmbHVmZnkwggEiMAOGCSqGSIb3 
DQEBAQUAA4 IBDwAwggEKAoIBAQC jLFkM6bzk7NOe+5kC7LE2ZOrfTHU3DOrauUL1£f 
VOQh3jH6k6fBoMSiPIzJWGcMil6dt/aciKgGl1r2G9X37BFOWYKbQOTjiKJu4N2tsn 
uXjWrKwEeDKYwnXnarctszzj65el74tZQlAXe/6nga83p-*fjH7CNOHIvbBRCxgFo 
4Y/9Vkl9zxbcqgVhCwrKyuxR7FNuPSSAgPA41GwYKYROICOTzzPOrDrSiC6CXhBQu 
7ivjL8EanoaaeGqiTFeT5wEm01YNvbAv+NrHPAHcyyOx jGzGXLRj6LKiQOBG/rfht 
EGGXHUf 4ahWL+yeWcORGNNcKkHMOWjdS+1pRb8KZn493PtPLVAgMBAAGjgcOwgcow 
UQYDVRORBEowSIYWc21wOmZsdWZmeUBleGFtcGx1LmNvbYYVaWO6Zmx1ZmzZ50QGV4 
YWIwbGUuY2 9thhdwcmVzOmZsdWZmeUB 1leGFtcGx1LmNvbTAJBgNVHRMEA jAAMBOG 
AlUdDgOWBBSFlwm401U3JIrc3uORcuQiz5iHUjAfBgNVHSMEGDAWgBSVRX5fK-*pl 
mBKRBPNjx2iaWBZ3JzALBgNVHO8EBAMCBeAwHQYDVROIBBYwFAYIKwYBBQUHAwQG 
CCsGAQUFBwMUMAOGCSqGSIDb3DQOEBBQUAAAIBAQCOoqY/YiguI7f9Pvc*XNj557uOby 
LKrjIluacV79TIKPd2dPB8ujwvnfbM8yKeO+RK43W9xTD jeBgOzRQvL5nIs31dHvO 
mmiiUiuBLObTCZ8 lwyDoENXVOHVRF 9Tx11RnVVETzy/8i4P8FOcBglmDzLGN8Mfa 
TrHczFTPbDtHRImH2Rbsr6/hEhMjHgrb9bX/XasVDuMlkQAOkNvYBxGQgQE6SKiq 
nrBiO0zbwDLcvpxeSUjYpFArWZYZnc3RuqjzuRzgeyG4GgYUCLvC2BHl1sONuBnLgH 
4wet+9S8JaGMEa4cONrmho/vIMAygY41tqwr4RLB4GRo4 fvpqodRLs3V1v28I 
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Fluffy’s private key for user certificate for example.com: 


MITEpQIBAAKCAQEAoyxzDOm850zTnvuZAuyxNjq30xINwzqg2rICIXIUId4x+pOnw 
aDEojyMyVhnDIpenbf2nIioBta9hvV9+wRTIMCmONE44iibuDdrbJ7141qysBHgy 
mMJ152q3LbM8 4+uXpe+LWUJOF 3v+p4GvN6fn4x+w jdByL2wUQsYBaOGP /VZNfc8W 
3KoFYOsKysrsUexTbjOrAID+NRSGCMETiAtE88z9Kw60ogug14QULu4r4y/BGp6G 
mnhqokxXk+cBJtNWDb2wL/ jaxzwB3MstMYxsx1y0Y+iyokARv634bRIB1Ix1H+GoV 
i/snlnNERjTXJBzPVo3UvtaUW/CmZ-*Pdz7TylQIDAQABAOIBAH-*bSvjiQirlWnnW 
YM78s4mpWeDr5chrvjmMQsyu/zQellu4551T9FgcOllDQGtpF jLaTz5Ug4nGYjVq 
3QG6ieL5mk T ddDH2R+z13sWuMmYOG2ZTaZ41VWdo+V/v8Ap+TIYHA2UGiwQSoA/3 
ROPLN31Taws8nE+hwiaGGsweujBvcaIJu4RQrGHRHaeEp1U+t f JcCHHElfzUAmKyM 
cMgF 8IpdUcAlpyHe3Pyc0oGnLyEVnv291xGWOfWT "T nat 7/KOODLAG6+TvbG3fGEYIw 
WK4DMraUbz66J1nj1XfADoxWOTsygV+KYhZcbwjBWAUSOSduAt fwa6b72OnWd28J 
8KYvrXECgYEAleCJZZSavxhlfxqsWC/WdQ8S3SimI62KSLrN3bIORO/60KiU2ap3 
16ZhNLa8t3DjpkWiZrukixs2odsU7k3z6qtqm++POTUwL7z3BriOFimqUeVSYgAf 
ZmF'gGz 7wLAM2 9zhvOhTZ jGrrwMINSyJ2t jyqpiOlXqkbdBpPBxKP rdcCgYEAw09f 
AM2QKOBFz jecPeQpwJanh8cuoHS+2CNLYGj1lmjd/zZAUgVF2+WPAIRIDmjAqJ9iwh 
15Yx3CbknpKbfhfilmHkcGyA+fjQaisq/NzN3Ya0OFP9Waht OFoBsAHt 9X5xFwXH6 
YBKUrqgoPF5DAy427ELInsIRa+LtoPaTdqpphFzMCgYEAlgSOOOs2FA43uyTpeF3t 
rmQOpVilaB7KFSaiGGBgUY7pOkoF9DwRsVT419sd48a7kb09ur2K08sHe2z8BenoB 
Oj-HiyNJHHSTXRjNqNBLuTP2fMU-uPDfFX/92n6WFjkXB*dlP8VSOxUkUjCg36/H 
luHMzQZFBKXXVOPTROG3GDCCgYEAoPEmq8QZOIA-*BbnzqVi8OQzfuN8geFyE9JrSm 
55JpKdTOHDbZXts3tDjMbZGI5KUuB9nbViGb/PVBbcoSTV6vtDOkpyq7O9a5gaCyc 
ZvS5PARFEnOvt9NACSHIxDZCldrU7EjaPQON3u4aPHff7NSK9haGD78gyPPOqIUsvp 
OLOXNESCgYEAxIUikI+5wXIrnC1FUtOgt6+4TOza7gEOOEpQRtktZ/1saNXEhA6N 
EUqWLJMOnClhp72V5IvXsKgjxU8VpgIZeHIIt5jZb8XMmBiSOxiVTf6rp3s8PqlM 
EtXfh7TdJzKuRP7d0g2uG4boJMFf590nqNjrxj9VeSxEWUrSK3YG/h8- 
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Kumiko’s user certificate for example.net: 


MIIEGTCCAwGgAwIBAgIJAJajhBdO74pOMAOGCSqGSIb3DQEBBOUAMHAXxXCZAJBgNV 
BAYTA1VTMRMwEQYDVOQIDApDYWxpzm9ybm1lhMREwDwYDVOQHDAhHTYW4gSm9zZTEO 
MAWwGAIUECgwFc2 lwaXQxKTAnBgNVBASMIFNpcG10IFR1c30gQ2VydGlmaWNhdGUg 
QOXV0aG9yaXRSMCAXDTEXMDIWNZE5SMzIxN1loYDzIxMTEWMTEOMTkzMjE3WjBWMQsw 
COYDVQQGEWJVUZETMBEGA1UECBMKQ2F saWZvcm5pY TERMA8GA1UEBxMIU2FulEpv 
C2UxDjAMBgNVBAOoTBXNpcGl10MQ8wDQYDVQODEwZrdWlpa28wggEiMAOGCSqGSIb3 
DQEBAQUAA4 IBDwAwggEKAoIBAQDL50dVdA3gF f /MuGIqhMY 8K17g7kUfexWkpXbT 
ptx1lxf2D8hzUX8/PUn2XXcTbPO01 9DGA+MkMiX4NNGpDZyeolIrcquKUXK7UQ1RoKy 
Q6VallDijHTqdPTWFIrRhbRUhPjjOWvGlAFPYRRG/IZfROCH8Aw1w8XSp614mlmY 
9XwL5LuHNimAgjADHMrSk1obmHwsOthU9nVOtl1UG1SA11A32JZX81bqKDg3Tq1Ho 
fsKU3GwoBZG5071VG5bcV2ByA5HnCFpFeDTDYE23197USLhqRtIqrxxr64SFo9Dn 
POmYH6e31RveAZhdKIbCHgGaKqIr7-*SZDnLdCyKDrFSPC/lbAgMBAAGjgcOwgcow 
UQYDVRORBEowSIYWc21wOmtl1bWlrbOBleGFtcGxlLm5ldIYVaW06a3VtaWtvQGVA4 
YWl1wbGUubmVOhhdwcmVzOmtlbWlrbOBleGFtcGxlLm51dDAJBgNVHRMEAjAAMBOG 
AlUdDgQWBBQO2bNX/rnbbYoEy6wU7oyst63WbDAfBgNVHSMEGDAWgBSVRX5fK-*pl 
mBKRBPNjx2iaWBZ3JzALBgNVHO8EBAMCBeAwHQYDVROIBBYwFAYIKwYBBQUHAwQG 
CCSGAQUFBwMUMAOGCSqGSIb3DQEBBOUAA4TIBAQCTN2SNTLUcvgtVnBi3RBRtDO+p 
aiFPtWO+YWbyCG/+NetesegCwi7xBOgSK+GxUWpTVuDWS5smyTTZyvrMOhpkckcyO 
KvuUVz0/yK670Sumelvo75KY8BvgfeZXZGA4PjqgelJ3czBOXLfeb6KFmtoiHQ/R7 
4i/09*MhB3Zoeg5bm5f£2g91jYwRbD1Uav/aH9WeGEX992d9XJ/bpGGPrAdgmV3 jo 
KDFKh8yslyfmM3xVdUOqPtos2nlzGNaqoceeFZoYaMf8uTzoaan6KZkQODTiMDRpt 
YKxyS721re/840FwDvt67w-GIfFf7ISrAlkHwroYtONMnLv6l0rka8qnVvaQ 
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Kumiko’s private key for user certificate for example.net: 


MIIEpAIBAAKCAQEAy+aHVXON4BX/zLhiKmzGPCpe405FH3sVpKV206bcZcX9g/Ic 
lF/Pz1J9113E2z9NfQ6gPjJDIl-*DTRqQ2cnqCK3KrilFyulEJUaCskOlWtdQ40ox0 
6nTO1hSKOYWOVIT449FrxtQBT2EURvyGXOUHB/AMNCPFOqeteJtZmPV8C-*S7hzYp 
gIIwAxzKOpNaG5Sh8LNLYVPZ1dLdVBtUgNZON9iWV/NW6ig4N06tR6H7CINxSKAWR 
uUdOSVRUW3FdgcgOR5whaRXgOw2BNt 9felEi4akbSKq8ca+uEhaPQO5z9JmB+nt5Ub 
3gGYXSiGwh4Bmiqik+/kmQ5y3Qsig6xU jwv5WwIDAQABAoIBAHCXmrGgRSOxWLBW 
PLbKm+iLSRsR14+bqwbg663SHTABI1Yzvu+W2Bo2oMnvMJrEe0o40712J6bJoZZvF 
CKmKqrYiKaJkXgrBW/ jtZ6xCWGPCNALIpnXIIWGS5tDIgj8SALOO4NT7hyROrrA4Rz 
WOvuVOSYFFX4BhvdxZesyRwCqn3x0pPSff95Ad+vuJa5CYuFZCuyGkszQO3fi+Nia 
GqsO1EuyolEv72rsw2E5+wtx3qXB8Z4HXr+Yq9NbE81p2CWd1Uh1qIH18kwWmn1IG 
V30LKiIowV+M6ZXx/uzwAMFORdn5kET+b5DOlIksUAAa8LZsf95rOvkLgw7aZaj5e 
SXhAdGECgYEA8930YqU2-*ACEkjC5hygwlM/X5k/IcvZp0a8/in2hJW7iZgGhOAFE 
jjxuoIVXbxSf9cZ-M6g76Svww9ecmovLArqbhFaLfbZCsrLeEAhQtGcu3wv70o6px 
NOEbbF 5FmOK7qgaQ1Sgqj ONF5zP2JSrxGNoRmgFFwVdcpP /3Jp/IIZESCgYEAlguI 
/7I8h90gldmTP zMpvpnANdRF / 1uMX 9AE4LNRp OOHjxOB7Vuat 1ABtx0O9/ZNIhLhZ 
BTZ5R2R2RjbzSHXZ3FdoMgSx9Q3qga+xuPel4RcppHNjdYkPDhPLnOUwOBgFL6kyU 
nTEF+k 6VIZVNsSmGDbBG6wpHU1IcjDAZUx71p 6W49TECgYAMHpa 7pExXUDTO76rH9tpCe 
sume5441sHtXOWbOAipVCugzeRdKmBWJIBW7YOoUS3yqH82JoPM81amqfwOJmz9Yh 
/ 5SY1AIwUJk-t*wQ9VnZJJmNM6OhTDvVFQOmE9VCEHIS/Mmox6FiWZ8EjLSJ7HvAZzzy 
Dqht bh 6wFW5WYM15zD3xewKBgQCRmIkY/QGFm0+Ih5ZMgB3eI7GGLB1sNe0nY1Ve 
DZvOpc3UQHOGITCLDuYLy91V908St17+V76JXIHDYy97U4baBau/kkgGm++gd9PJ 
UIIXg8aaM73rUJLXhW7ZH68rA16jOnI4tpcNW5S/prS5InOUYI/hXkT7psPIZAO8w 
OV81kQKBgQDaGzCYC/ 6NumGJUerVCzZd/H6+E3ntZmtz273c8+wV890RtZzUoJY4 
bVNrYFs9iKFxLENGRECEU2VZDXHUAgugeO5rbzPudAZ4wSsrNchUyw8LkIXHDckt 
pVLsOvhRK29gW/W21tp2exSPOPt3Uy8tT6ISsB9ZbNg/HAD160heHkuQ-- 
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Domain certificate for example.com: 


MIID9DCCAtygAwIBAgIJAJajhBdO74pPMAOGCSqGSIb3DQEBBQUAMHAxCZAJBgNV 
BAYTAIVTMRMwEQYDVOOIDApDYWxpZm9ybmlhMREwDwYDVOOHDAhTYW4gSm9zZTEO 
MAWwGAIUECgwFc2 lwaXOxKTAnBgNVBASMIFNpcGIOIFRIc3QgOQ2VydG1ImaWNhdGUg 
OQOXVO0aG9yaXR5MCAXDTExXMDIwNZE5MZIXN1oYDz IXMTEwMTEOMTkzMjE3WjBbMOsw 
CQYDVQQOGEwJVUZETMBEGA1VUECBMKO2F saWZvcm5pYTERMA8GA1UEBxMIU2FulEpv 
C2UxDjAMBgNVBAOoTBXNpcGlOMRQwEgYDVOODEwtleGFtcGxlLmNvbTCCASIwDQYJ 
KoZIhvcNAQEBBOADggEPADCCAQoCggEBAN10BgIOwucEH7yMtiTnmb5SjSDeFnm2D 
EOoROGo5IsfqGjKeAub5S7KbKYOeErfZOhYIWfkA420ApOLCCpag5qfzXPCcHFjfelD 
ZAFM6rUetOyjNOh71Q0qcwdjnYllvx/UjuZnYHX36gp6bJCvkkXgYgWaihCY3HxU 
i+Rh1TSE/BBQ74BFul6H13bBICXBkh2JCvdVYmT66GmiYkxnOwjZYbU9F1S2tOSN 
WSuQ10n7x32HWMMS rDN4AFC6BwWzuQEaY1Vs4XrsoweuOwKDoWngw9wt Yemy4 INS 
yKbP2vstmcflcbnJF9TtvKBHVAmMbm1TmizJaMZv8T2RGiRDd32RaUSCAwEAAaOB 
OZCBoDAnBgNVHREEIDAeggtleGFtcGxlLmNvbYYPc2l1wOmVAYWlwbGUuY29tMAkG 
AlUdEwQCMAAwHQYDVROOBBYEFMwGWVuLXtYN8gVNG2hUHvz5QxkXMB8GA1UdIwQY 
MBaAFJVFf18r6mWYEpEE82PHaJpYFncnMAsGAl1UdDwQEAwIFA4DAdBgNVHSUEF JAU 
BggrBgEFBOCDAQYIKwYBBOUHAxQwDOYJKoZIhvcNAQEFBOADggEBAGga0dsAS5CG 
SFPqbzAxiR6bCRS9b7kCqm9Y7jADuKH9sOFy/7MNy3anF8ZXOAYT5fPKMBAN95el 
83Tpgf jOVaMN9YI4w5hDUh+EzRqOoOWfPeIx/cuirelgffrSaqkkvQamAAbvttnXJ 
121/DJFg8cRaNuhcrOGo55pV5eDNAfTek /Q4bMFxOv3NG10165B7MUHnNw71wAFI 
kfcO3cYfdOYONObNkw8/zpStkdnicrGfHdOlfV7ipFbFsXFNEApdplbmVx9IpVxl 
ZtqrNT72tvrB84rBgHEyGGwztfoWWhbhoWwZ2Z/VFaGRvsjHc4loastSHiZb9h704 
TgoZBwNLm7E= 
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Private key for domain certificate for example.com: 


MIIEpQIBAAKCAQEA3XOGAhDCS5wQfvIy2JOeb1KNIN4WebYMShFAajkix+oaMp4C5 
vlLspspjRA4St9nSFghZ-*TjZACnOsIKlqDmp/Nc9wcWN96UNngUzqtR63TKM1CHsh 
DSpzB20djXW/H9SO5mdgdffqCnpskK-*SReBiBZqKEJjcfFSL5GGVOwT8EFDvgEWO 
XoSXdsEgJcGSHYkK91ViZProaaJiTGfTCNIhtTOWVLa3RIl1ZK5DU6fvHfYGYwxKs 
M3gAULoHBbOSARp jVWzheuyjB64T7AoOhaeDD3C1Ih6bLjs3HIps/a+z6Zx+VxuckX 
1028o0EdUCYxubVOaLMloxm/xPZEaJEN3fZFpSwIDAQABAOIBAB9s231ni4Dk4OwM 
u7w48acCFLlsSLMZqoMEKwCN6FOA4zDTo23LaqaJxjeOUMuuKVXfEYWAP6r6RBCIM 
VHOLOMOOCdLNX4y+d+2tUJErLq+9aUUu093ebDxcMntk fh6yNyUS /mk /KOMbpFRT 
ldn80WxSJc19IGyxArkB7/9UEcDut6vzdbz+agXpHZH4T jeSOWZOXkHzsYobM8Y8 
c2XwudPlzdQtvOrrOeirexxpOOf4CBOnBxoGmbae9Wf27Kw2bBm5-*blZFgdqNxoh 
603rJ9EDyWkrVMAq9a67a59wSTlymyCOc6FmfToCMGlgoMPHcEdvuNYPWd23220K 
ZdfsawECgYEA+AewMi TdhAE+ 9TId2qilLOV+y8bdTHO9rSqw9SF+q5ShO0pZa7 9ER 
asuDuqxU-*TiewSOircrkIyzOmCclfnfBJh5y6GukpUk8HdLLkA29fV3ZJe-*YAZbL 
bATEy/RxEECQREgtnQiaw08yOlTl1dobNwxzVsi3mrhtOpfbPBERZUSsCgYEA5JG2 
aGRCkyzASGAnZmqgqXCP /pImU-*tJb20CgQ6/3gsxi/l91LwtRhFgx/ptYCgZWlpbz 
-tmpnDqexKtowldbjorrUADw84zG4u9dtuWOCXEpCVIEu4DZsRURdy3OzpK1vJaUm 
NLgBiDj8JkUFrXTi4RzxlXysf6ndWAxDPDdI-GECgYEAoyFrYYtdohSvs9UijY4e 
FV5n5t8E7iQF7L72SoOdLHylDjOV2-*VF7lerbDusJ751q9hjlqp71Iid3ips/M87P 
2qJsMTGbOJrSTOslV6mxl6LCD5Fmm/jyFIbeaMZ9FpNgTA4ipd38RSyPrhTIbv7kp 
3Ao7AtXtwtVzBPUvcz8A/ 8ECgYEAw2ps2F13qdq13nsO1IHo3gqVoaGUUUU1OK2MI 
wjYM1/AkZrR4PKthmi1IPIEpT/tTpsBz2yBBO6XoYya5+10DWzOyoGHN1 jeR7GgRah 
hqgCOEHGQuizkRd9hu+rSgiI+oXmCOF4tBv+W17+YnKOAUidP3gTgIZUAG6fjxe9io 
FzBxG6ECgYEAyAHvSeqqwmdotdpWgR3Fk1CmtH7ZPnF2rsuRBaBoYnWtU619ote- 
+Bmd4 fBUB9tQOZUC9desRtoK3+w1JKHEP jm/OFxtQQi9o0gHEn4e6P9jOwXJNkSsa 
GjGUf£zQ3Vm2baeNMg7sH8C5mQ9nskDuCzdlVAB2bMp23oPl6cvPIbOE- 


Jennings, et al. Informational [Page 48] 


RFC 6216 SIP Secure Call Flows April 2011 


Domain certificate for example.net: 


MIID9DCCAtygAwIBAgIJAJajhBdO74pQMA0GCSqGSIb3DQEBBQUAMHAxCZzAJBgNV 
BAYTAIVTMRMwEQYDVOOIDApDYWxpZm9ybmlhMREwDwYDVOOHDAhTYW4gSm9zZTEO 
MAwGA1UECgwFC2l1waXOxKTAnBgNVBASMIFNpcGlOIFRl1c3Q0gO2VydGlmaWNhdGUg 
QXVO0aG9yaXR5MCAXDTExMDIwNzE5MzIXxOFoYDzIxMTEwMTEOMTkzMjEAWjBbMQsw 
CQYDVQQGEwJVUZETMBEGA1VUECBMKO2F saWZvcm5pYTERMA8GA1UEBxMIU2FulEpv 
c2UxD JAMBgNVBAOTBXNpcG10MROWEGYDVOQDEwt leGFtcGx1Lm51dDCCASIwDOYJ 
KoZIhvcNAQEBBOQADggEPADCCAQoCggEBAOwsdgPVSPMweLWSBDHUSXJS6Vk6pu6K 
sVg8IWMf1gOTWTPc5 JUAQIWILNtmN4gcSzq5zlecvf£3rLMomJPZaWwbektTTg1KzZ1 
2wQgyP-tvx/HflBByj3s2DE/KZoLnQjFQawHHMc-*kCtSa6dCFTmD9nA5cYDVxNmKG 
Kz/*5HYxe6ByI6NZGNISB8ADPULCFg6UChO06JvrGFtln9tAtMf5C314YYGpqXBl 
qZov8WoO0Gp6VlndA4LrvDZkwjpQ/o7EuFbiK34Gvh3cuh9EkMbk-*IPgVv70ohjWPDl 
6WygTkE2VXHDhhdNAMXPKyenXX35sB52fNytN*2qM8bo4Q0PfTZl1GrxOCAwEAAaOB 
OZCBoDAnBgNVHREEIDAeggtleGFtcGxlLm5ldIYPc2l1wOmVAYWlwbGUubmVOMAKkG 
AlUdEwQCMAAwHQYDVROOBBYEFNiNYjKOu6f046JHy28GDRVMeR7sMB8GA1UdIwQY 
MBaAFJVFf18r6mWYEpEE82PHaJpYFncnMAsGAl1UdDwQEAwIFA4DAdBgNVHSUEF JAU 
BggrBgEFBOCDAQYIKwYBBOUHAxQwDOYJKoZIhvcNAQEFBOADggEBAHUZR2H2TWrQ 
ls3iqN1G7815mOjm9mgOX6WP21LwBOTOqtPJ9uE2XZU9qw6d9vdcbAgLpp4Em4T7 
WhcsOzVTrgKpWjDlho/boRS1gP2Qu9I86zJzf2R3mhTHUsbpxIwMCcHOg/ fdIIeP 
5Ar8R5DZXx/Q9zdQLE-*cjMSjxo7q7u0V8DRkgMpYtp7BURg5ZXhnkAhEHxa3/SbU 
YGfy3PzRoAMQOmRZieAXArsIxEfkaC4Dtox/DAXLvY7njBFv8H6wqlvQyDsKXWlUH 
8dS9i/3wFEpQtymUUeXwk8gzf2ytT6hgrX70s6BLy/IeRU*wLJ3k5YZpopQZjDml 
fNOG/O8TJ1Q- 
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Private key for domain certificate for example.net: 


MIIEOgIBAAKCAQEA7Cx2A9VI8zB4tawEMdRJClLpWTqm7oqxWDwhYx/WDRNZM9zm 
NQBCVaUs22Y3iBxLOrnPV5y9/essyiYk91pZt6S1NODUpmXbBCDI/6/H8d/UEHKP 
ezYMT8pmgudCMVBrAccxz6QK1JrpOIVOYP2cDl1xgNXE2YoYrP/7kdjF70oHIjolkY 
2VIHwAM9QtwWDpRyE7Tom-*sYW3Wf20COx/kLfX5hgampcGWpk5Xxa;jQanpWWd3gu 
u8NmTCO1D+ jsS4VulrfgatHdy 6HOSQxuT4g+BW/uiGNY 80XpbKBOOTZVccOGF03g 
xc8rJ6ddffmwHnZ83K037aozxujhA99NmUavHOIDAQABAOIBABfBYR2BlpTfi0S6 
yLE6aSjWriILhD76NFxrr/AIg79M8uwEjCNIO2N5-*ckXvv4x219NOUO-tt2Tii3L 
KGyfKecO6isncjxKgnOnzw/o3n01z97Xpxb9mL9t 3GHOYRoUvK6xGpGILo60B1Cz 
F+8pk0jegc7eVFoUpMULHm/FCmpY3O0N5cvCHcAE/ncW4 9bZmH3gQ+cmr 5UCKKDUY 
baJyLd8Q1ftuSmt rfYZzRT5c+4wmrBu jv3w9poMJuEo4s1lRaDnyeKJPSNR/6/LIk 
tqnqgNif9cj9wqF6hWA23dDmmU/kSRtnl1KOz5XmV9Jbo4Fu64Fvn/m/hj5O0gA4CP9 
hZUWIQECgYEA+nV2pzspCfS7jSebVnvjChvqJOnJAilSqCmrSQIT5PRmO+GOs 6 UT 
PVN4GEOMS8TTJyvxVkpoagQ36VLw/Wr0 jum+Z+dvITIIFWTas8RNmdZHMvOLvfEe 
Qu2fTI6812d/LIGBMUCYa/sucX5E9q+3LC+Qo9jw8ehWjQZsWYER4dsCgYEA8SWYX 
AgDdKjHRqu2h248gZsuogiZqO5iuzXhk2VTQoiM92mu8mIHtak+eov3/ 3wo jqxuw 
TAQbf/t8EfQ7LIGjaKqgAua7mgG/aNB6MGGwdpBAPUZDL+DuKfbDbzTOL/IuaWOFp 
40RCOUp5nTU9wzIKB7a6n5S5ROKXxiGUIphfcGcCgYA6IYdPmziUOfxJ79ZrBUgV 
8Z2KwWbzOxpyLsVgzEsthSaRs45a9S2QiyLvIECIRm25S2i0ilRSU/rOncPvEJc3q 
+SG7Zgkb146p3 4WvUbGdMhHGcNsH0+3tJM/ jagGltmzbwWmV7+Mwt NT 7vI3vH6ud 
EuUkUlbiHsXv53zAbWekHwKBgBy5HwfLCEXbA6209NdhlImPY28YQuClRQ4tjReyu 
MNz6AIQayahZiTxbGO8f9fAeDrxvYPzKiFMkIlEnlFrpWf48O03DcpMSninklIVpO 
kwBOgOIdrods3j+yaZTIzCzaTjVxKXk USfDjW+b2A9kZhj9v3HCGc2qb1/5Utraio 
JMMFAoGAHb+k+C4e8WrW+ jXbbG/DgAkSokK5vZwZLHeWBig 9bEi 626xN/oFEQVXp 
zqwyNo6zQaofmS6anT6P2M7NC1SGJxh27eBTiTLpINCXIGTWAQEtXmYtvnAZNzXC 
5UrOwvS5bLxOnbhJwN8ZBwzJhYupOkU3pn99GcF-*vkj5Eg7Zftg- 
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B.2. Certificates NOT Using EKU 


These certificates do not make use of the EKU specification described 
in [RFC5924]. Most existing certificates fall in this category. 


Fluffy’s user certificate for example.com: 


MIID-jCCAuKgAwIBAgIJAJajhBdO74pRMA0GCSqGSIb3DQEBBQUAMHAxCZzAJBgNV 
BAYTAIVTMRMwEQYDVOOIDApDYWxpZm9ybmlhMREwDwYDVOOHDAhTYW4gSm9zZTEO 
MAWwGAIUECgwFc2 lwaXOxKTAnBgNVBASMIFNpcGIOIFRIc3QgOQ2VydG1lmaWNhdGUg 
QXVO0aG9yaXR5MCAXDTExMDIwNzE5MzIXxOFoYDzIxMTEwMTEOMTkzMjEAWjBWMOQsw 
CQOYDVOQQGEWJVUZETMBEGA1UECBMKQ2F saWZvcm5pYTERMA8GA1UEBxMIU2FulEpv 
C2UxDjAMBgNVBAOTBXNpcGl0MQO8wDOYDVOODEwZmbHVmZnkwggEiMAOGCSqGSIb3 
DQEBAQUAA4 IBDwAwggEKAoIBAQC 6VyOIP6UANXy7 66KHiYDxyOpYEFboLJv6SEtw 
UWQoZS3hQurFidOu4gkCspbl1zaMoty71lnUexbFxUKdbJOWGMCB2hrezI+6rwgPK/ 
bF5YDijVtVaMRd51v/NiS5yzteHfrMszWnz3t+ojgak 4XT jBJmP2ROOT67GUpEbFV 
sDeYtWi+GI1IebDAR6bf6Jdba2K6DnmkxT5Rr60YJHTApYbubk28asBON6EGBBgPEO 
RReJYrjoJR/rBDDe1bxK+ONdFXPlwjI/TRPMpvUYraWgTjJ18tXISgFIhtaa/Y1K 
YP79Yun2N1/3UQCPIC/C6CXBs3yAUK3qQO1G6C5pXH9KMMINAgMBAAG jga4wgasw 
UOQYDVRORBEowSIYWc21lwOmZsdWzmeUBleGFtcGx1LmNvbYYVaWO6Zmx1ZmZ50QGV4 
YWIwbGUuY2 9thhdwcmVzOmZsdWZmeUB 1leGFtcGx1LmNvbTAJBgQNVHRMEA jAAMBOG 
AlUdDgOWBBT7CTX1Q5GKWvxGZNY24mmmVuEnRDAfBgNVHSMEGDAWgBSVRX5fK-*pl 
mBKRBPNjx2iaWBZ3JzALBgNVHO8EBAMCBeAwDQYJKOZIhvcNAQEFBOADggEBAKL9 
WUWGRhHCQdhjzY4bxORS5Kwz+NHvsb8rjlPqfdcbNu jBCw+rD+/uux0G3HwWt+Mraj5 
U2tUehwz87k6SgdqADzL/CP2mjzCJo5uDhittz jeg6Zk1TSZYQrL3FSv/AgcUfFI 
9HuCGkix/htaoEMy2zNZnZOjdtFME9w7wb3GxxqWIUzl9TToloCXYmLeQo/jwuad 
40ybun1P5CWkO5Md2Y5zuNfCsRRz51LYtAVfANtLBfeFV+S87AwrrdelITT+iyB7H 
Jj+t24U4TMC8MttcHBIPPBuRVc2kmhNEQuTzel1lCsldXgY2+kn8ItnLdv1mvLpXA2 
2Y41CPLCSj9AlqgqZL9I= 
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Fluffy’s private key for user certificate for example.com: 


MIIEogIBAAKCAQEAulcjiD+1ADV 8u+uih4mA8cjqaWBBW6Cyb+khLcFFkKGUt 4ULq 
xYnTrulJArKW5c2 jKLcu5ZIHSWxcVCnWyTIhjHAdoa3syfuq8CTyv2xeWA4o1bVa 
JEXeZb/zYucs7Xh36zLM1p8 97 Eat 4GpOF04wSZ j 9k TLEE+ux1KRGxVbA3mLVovhtX 
mwwhem3+iXW2t iug55pMU+Ua+qGCRyAKWG7m5NvGrAUDehBgOYDxDkUXiWK4 6CUf 
GwQw3tW8SvjjXRVz5cIyPOOTzKb1GK21oE4ydf LVyEoBdYbWmv2NSmD+/WLp9jZf 
91EHDyHPwuglwbN8gFCt 6kDtRuguaVx/SjDJTQIDAQABAoIBABtIBLi+8KS5eJlvw 
/MOxOwKrMrwf 8ElftppnGTxhf jN31MbFIFA5hJA3GnCdqwAMIlYks6YEZ+mu/rmH 
wp2FXCXOiFgSebd8tCMilbO27v0fXZUkTxR4aj41YOHYrLg7yfrSXjER8WQlKPMK 
PVKmLOWpk 34+2 jOOhqUDpR3xhcJCIQ81fC1IhKe2JoixNDoPdfM3azTq8QUPLOD2T 
mjww11H1677G50/6qMloOMOFeqv/3cUWiRmvPv4eyGHdNtuFXKFpBADQOMQL7TD8 
FOOHBymHIOZSSF+gYgBFObOYNgu2CqgqZrfEDIcfOrRotrbXf6tM+akc1lxfHhkfKaa 
JPZOSbUCgYEA4MaetKsa7azhEYMc4TKOxhhVS5Hi61j1IxR/6h++uYFOOIOBjMIyU3 
5n6vLpyghNbw2bKO8OIWPOOF4syvyKYR2elmUDraH2 ODKALTRLEKU9K82RG4AmXmk 
G6ZsWOfx6Jf350nAKVj/7aN9jcA4K1v6EFyQOGYEXDbp4IOfhFfbJBAe28CgYEAlDmx 
iKJD*jWW9ypHk51YJ3rta5qPPNVmjGKQOje3Y64rSlxmWOhMwXoCBOYRwhHBRA// 
SxXH93PZ8rECjNkhxp6Ao87X2Gcol5U6kH+rwfd/3+SsHqPrugaDIwN1gkcu8VRrP 
8uP2CgJoDBiS5UY2UR97GVK98x8k2Sf6kDT32mQMCgYB/KH3R8VY7jOiKcqTcIUWl 
JIE3/gB4S+wQ8YELthOFVCPOsDsLuZdlItfRw70fUraa01k/SHeSIfiJaIghN6mz 
oDFMO+T7vh47zUWurZzPCg95n4nkS5ihIKNRInV9elJTudjLcWS3pFyC2JU3XIObE+n 
k66zufFoUuWFSCi2juibqwKBgCT6RHelJjkDe2FniX8r7D88y/W9wXVtDWgqiE4x 
XQ/OfP8A6IjBKTaQ5qcp2zBAXbdZPjc7VEta21A8FvQPXVZCrsAAFXha4413zVsO 
WYblLITI7ZXA2yvU8wW/GndsO0zUliTRGX6W-sAYOrll/M8k/tOknA5HfeEYsEbq 
Y/w3AoGASjoC9Fjy2aBvH8SQaimn/Rx3hOFRAmyOGWtHxrXmezoO2YdcMOld8rlz 
A/SQRvVofHRwyoalkZkALprEGyxEqCdMmEslh9xYAcxfW23RfqC39DYb9RTrRkwa 
ArJmcEdRESOsIYhhXGfEl10MGiwjlUXMWeYcLtqQOKRWiLLDTYYfQE- 


Jennings, et al. Informational [Page 52] 


RFC 6216 SIP Secure Call Flows April 2011 


Kumiko’s user certificate for example.net: 


MIID+jCCAuKgAwIBAgIJAJajhBdO74pSMA0GCSqGSIb3DQEBBQUAMHAXCZAJBgNV 
BAYTAIVTMRMwEQYDVOOIDApDYWxpZm9ybmlhMREwDwYDVOOHDAhTYW4gSm9zZTEO 
MAWwGAIUECgwFc2 lwaXOxKTAnBgNVBASMIFNpcGIOIFRIc3QgO2VydG1lmaWNhdGUg 
QXVO0aG9yaXR5MCAXDTExMDIwNzE5MzIXxOFoYDzIxMTEwMTEOMTkzMjEAWjBWMOQsw 
CQYDVQQGEwJVUZETMBEGA1VUECBMKO2F saWZvcm5pY TERMA8GA1UEBxMIU2FulEpv 
C2UxDjAMBgNVBAoOTBXNpcGl0MO8wDOYDVOODEwZrdWlpa28wggEiMAOGCSqGSIb3 
DOQEBAQUAAAIBDwAwggEKAOIBAQDE/QVN7nxDDu5ov6bOcmHIFH93KhNDbTEyCisir 
i4OeUBiCv9dgRgPBXffrIIVOdIlCoDeLDusHdsCOEfFWvg-*pRlKVEDgwccOOF5AV 
bq3MK2Njma5I0lwpIaORXYQOK//oX/tjZeakhFty/R9yerOKaXWdLRd6KtncISui 
ZOrFhlTB91Hg6vNJUN9-*Xonbcs7siXbj3qZzdhb7oipI4PoOlXVetyutSzAVe6MsU 
5lwLmpOpIzOdSsJyxaAsWtAsyxunhWWiPZ888UMAvXjacZ2uj8GvJ8w2XjgJilOvV 
s80jWMKnAGLaR7grTBmGQ90e6+cg7hWuoGBIQAOROh8zWQz5AgMBAAG jga4wgasw 
UQYDVRORBEowSIYWc21wOmtl1bWlrbOBleGFtcGxlLm5ldIYVaW06a3VtaWtvQGVA4 
YWl1wbGUubmVOhhdwcmVzOmtlbWlrbOBleGFtcGxlLm51dDAJBgNVHRMEAjAAMBOG 
AlUdDgOWBBR6WwH61Ul7BIWeiKM35fMAiE9xazAfBgNVHSMEGDAWgBSVRX5fK-*pl 
mBKRBPNjx2iaWBZ3JzALBgNVHO8EBAMCBeAwDQYJKOoZIhvcNAQEFBOADggEBAKES8 
y9YyoZlkFwAWxPalK087sSEveKBfzh4TuYQf5YcSIPwOcoZGj/gNxn1juiYhE93G 
F-Si/hJMOM6cc7SLB5Spq06Tt3PyPBIOZOWk9koh92kDI3axSr6II9Plsvp*tXsrl 
bz5Zy8njy/YZrk/qOaHqQ5J6nPNp5qwF-4ns2t-52188Lli5nkBgOXFOuEORIkcdF 
CUFRUjO26GxXAILRG6wUThOz f qg55Azw15Y9Y9QmEjFhkbYL1sOOHxcJdnt+6Sdm/vN 
MeMJZdTzp1x+8pfPhJgHoyz 7nkAxhgzC9RT33ra33BNkMO6esR1QONJ+ZRSRLhHP 
O7+kvXvmj 9AASA291wY= 

er END CERTIFICATE----- 
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Kumiko’s private key for user certificate for example.net: 


MIIEpAIBAAKCAQEAxPOFTe58Qw7uaLt*m9HJhyBR/dyoTWOxMgorIq4uDnlAYgr/X 
YEYDwV336yCFUHSJQqA3iw7rB3bAvRHxVr4PqUZSIRAAMHHDtBeQFW6tzCt jY5mu 
SNJCKSGLEEV2ENCv/ 6F/ /o2Xmp IRbcvOfcnq9Cm11InSOXeirZ3CEros/axYZUwfZR 
4QrzSVD£f16J23LO7I12496mXYW+6TIQSOD6EJVIXrcrvkswFXujLFOZCCSqUKSMO 
HUrCcsWgLFvgLMsbp4V1oj2fPPFDOL142nGbo/Bry£fMN144CYpULIbPKI1jCpwBi 
2ke4KOwzhkPdHuvnIO4VrgBgzUANEdIfM1kM+QIDAQABAoIBADuLR+kwp3sVrlcX 
Z3AIfSOofmBALNeKpAA4-*KJ/JCr7xQ9bfACXhecZAnuWLnZ6TUNRFgoKl12DvEookYE 
gHD57n36dcf9KR7rpH5xiOoRlJNCoiRfNeFpRNZiCZBwNiAXFLnHGtznVnpwT7xI 
axMNqgsrU6epi0O/quAPkOu5x6e0+j+j3ZauI4EfDIlw2R6moBMUt ATauZEEyLuC9A 
6bFz2AFDchPVLwSjNMuOtAJCc8Fss8xKl1s9HUXGS22eUfHxWfkCGwChuW600bGmas 
E7GS7h4g9QvvQ4hGSVy9/MmQ88GmTOLynOyzFBCpuwjOQTHwsD6741dMSLAkXYVK 
jenTAkkCgYEAA4bjN2ILis3uWTjvTNnrmWn1QoZBZDhglLuNsb5olXtOJ7CdkckUvs 
nqgQYOzNk/9N8vUsl12ds3csXHypuuGrJwAVf648RSPDUUQ2XOOPSL9NeuZt5Vl1fT 
1VyVWanKCBZ5sztISNVPt 7Pu8DtGLHch4S/7M+gEUQB10gz7fyJHvFSCgYEA32mE 
61N67aHkqMLa06Z219JIk/3SsFIPpjwZ4tktsQCqEzawPvkT7qF24*U81VtOXXKJZL 
aexsopsULCGS86TEAPoYtjjk91p6ZZj8mgRZLUS55g+gRdTpAFhXMgIctU7U6cDIw 
SPa6UxJp9XCa/Gf6YLfas9VBhc/80C714ygjLDSCgYEAgAG7yuM/CSY3MRrARw8f 
fAW9qkIgHtwfnP2gjobtjEk8GXOkvcle4QQ09aJoiY6HPZM8hpO6kUIuSCzyXGCKF 
s33Yzc+Or9zTqzuX3b1QA4tNFt1SOPOf OEn28KhHXSIrmbXxbG+LMmINUF 6ylusSW+ 
cuQxAli6ye0Gjes63PhlOiOCgYEAuECILGOpTGMyAYWgC93n5Vu6ir-*IxO89sgyL 
ewlirhakLiWTYsTxsyGHwOKb4iO0IWOEHWVp7DPDPhcs3tCIezhN8WKm7KtAF jlHO 
YZfemsFU99lutPwUKmNWqFlXqOkeR7cOHtDsRWM15045uKJUnYmmkSptHjYFNsGXe 
q4fKA0sCgYBoAYtsLfMlqt7s3htx4hZSMFDbLP/iMGW2DMMAzDW-Xxsvw86ibrcWY 
8c3hbohuJBpyAzba4QoR2G+gtRmodLca+tQFMrObETHFg1NCY+WoHRSNRImbCS8w 
dsszPgHWfInrxBLBiDFIHZwSqbZtLyBjPIHJ+£TiPNoG6UTx8aDQ4Pw== 
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Domain certificate for example.com: 


MIIDITCCAr2gAwIBAgIJAJajhBdO74pTMAOGCSqGSIDb3DQEBBQUAMHAxCZAJBgNV 
BAYTAIVTMRMwEQYDVOOIDApDYWxpZm9ybmlhMREwDwYDVOOHDAhTYW4gSm9zZTEO 
MAWwGAIUECgwFc2 1lwaXQxKTAnBgNVBASMIFNpcG10IFR1Ic30gQ2VydGlmaWNhdGUg 
QXVO0aG9yaXR5MCAXDTExMDIwNzE5MzIXxOVoYDzIxMTEwMTEOMTkzMjE5WjBbMQOsw 
COYDVOQQGEWJVUZETMBEGA1UECBMKQ2F saWZvcm5pYTERMA8GA1UEBxMIU2FulEpv 
C2UXxXD JAMBgNVBAOTBXNpcG10MROWEGYDVOQDEwt leGFtcGx1LmNvbTCCASIwDOYJ 
KoZIhvcNAQEBBOADggEPADCCAQoCggEBAKEVuYyZlaqfgks9u9yWORp9WfI-VsQOg 
GpJH3vAfastElCdxlBV7-*R2CaQ/GnXDnEOlAC5SiKRcvPHq50Lx1VnDADMWmcXBv 
wK5nlzNt*7MUCy/MISMr7E2Nd*py8Ft3XhjWDIuUljAhA4HDO4fxS/BFy8zOzADxvP 
OfpE40EABF 5aj7e+xjtkErdkMybAcSYyo53THP 3wDPxmMzCsOw/ fi8bfy9j1GiUD 
uz01F9gT/OpzIKISNXgTIIK6GRIktG4JawSiohW1QbARfj9//hR7ZgeBOgO6LLGX 
CcGXd187JdA4ZHMZNinN4Cv8ctzYSQz3dbt1pRRbGtq7e1lPskiinDuUkCAwEAAaOB 
hDCBgTAnBgNVHREEIDAeggtleGFtcGxlLmNvbYYPc21wOmV4YWlwbGUuY29tMAkG 
AIUdEWQCMAAwHQYDVROOBBYEFFNu6jHPsItA-*vy/Jqv81MW7wLJpMB8GA1UdIwQY 
MBaAFJVFfl18r6mWYEpEE82PHaJpYFncnMAsGAl1UdDwQEAwIFADANBgkqhkiG9wO0B 
AQUFAAOCAQEANH+wX5 6VJd0VVB9+Mef1xItWrSQUyNYZZCBqty/5vIoOp6Chaupn 
x JT IWE50zg6CK8yKBWq8pG1G45GTUx+uCx+nVIbHpyTT5+YDDUz1IhhAUzIO0B33 
Fd/XI/I1PK5p5ftuJIYXUOrGuaoH8ud/p2nhIf9mwicUHxViTX3PUwlFC7eMbevBo 
8/dMYnHb2i40ug6hsiYggsmQDbhHLVLo/yqgkpvgzPLSSlkXS4sv20IloJ/ISuSjhP 
QkQ7mh7h01ct/LOa53qWfbCVogQDhMEqPTVdPm-*JzTrMlWeZdrk4KbnXGp64Jtpu 
XTVI4GCVAGWUT OcmpspDmHbPOKm5kcltkg== 
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Private key for domain certificate for example.com: 


MIIEpAIBAAKCAQEAoRW5 jUmVap+q8z273JZBGn1Z8j5wxCAakk fe8B9qy0SUJ3GU 
FXv5HYJpD8adcOcTSUALIKIpFy88erk4vHVWcMAMxaZxcG/ArmfXM37sxQLL8whI 
yvsTY136nLwW3deGNYMi 5SWMCHgcM7h/FL8EXLz0 jMAPG885+kT JQQAEX1GPt77G 
O2QSt2QzJsBxJjKjncgc/fAM/GYzMKw7D9-*Lxt/L2PUaJQO7PTUX2pP86nPOrWyf 
GBPUgroZGWS0Obg1rBKKiFbVBSBF+P3/+FHtmB4HSA7ossZdwZd2Xzsl0Dhkcxk2K 
c3gK/xyllhJBndl1u3WlFFsa2rt6U-ySKKcO5SQIDAQABAOIBABIO9gIZAOedZLxJY 
Cja/ONA4EBbRdhLuumvOnecIc/J3JxTD2Nnt8TOgdJUJpDhjjwZZQzz7kYdzDN4j6 
Akeszb30sT2MIFob/WiCT6cAH1VrrKZ3cK6zYY217aPjlH81UaUrlT73UnT/DMp6 
gMFbo-*XQZ18evFc8zubc*BK7KsNANb6/zMhwt*PXEiyg2EGDN1FoA4TMhxPDAwBIMU 
80LlE8A6GKimxAk3gMuliS6Ruau2HpGkjkkHkAx/yzU1s8BCMOLDJjyyHl9PRISr 
nOVFfeOgMOaZpaZ/94ynFPdMnBXTq8BabTO9eiycuLKlLOg/ERmj6jIImGSYRWED 
GzlzXOUCgYEAOFDUek2uLhyltXwlzhDTldyuItiYZq/MeXaq2eA96zhJlD6aX455 
PQIxXEEfhgTNf4e4cKjXQOSD7aixy7jp/kFGowFRIB4pwbLDuhlniYSxa8Kv0OpJM4 
DTAGue4QFZId5Z243KH755Ub7tjrCEIdOnij44DA3gPnjqgXk973pdyVcCgYEAxfUx 
/ zMXgTp7HxW-QHZD7xXESsA4FplxjzL5BaHoJnM7WbmkWvUvcMaEE/i9RqpyGlXRiN 
jJX6KBZOUVgh/BO/AcYMa3DImTa0+Uie9kN7jTi5pzvIUAdFhH+RyQ4tULWr5cgrzv 
PjGG9tXMthuIbILSumVEwvC-P6Ksilr4xplezl8CgYEArF51sk2clqMlqpnzXjMm 
IJbdsAt*w6ycD9mlugaGXGo8UswmqCz70KrspheMOgQfVisjPnU2x71Wz1/AKcdVz 
kEDAUF£54FxzT4J4D13zBg71I3FxORXVbp+3ZYvfNbOvcWSc1VN jcRg8aMIsmES8m 
UfhtFnRPOPWMn6qgmyQOVjnTkCgYB/3zlinkBKq900ZEU3Ig4TXL5pLemOloFQcjCk 
kJvVnTRcXTM5pngPSEaiLp60Q3-*sOVYGlnyVOSwLPwW/VVb8fDH31lzWC66vcKeuc 
Dz5JnFWgS5mLiIbzly/wTaochIOJIWWI5jIigHc9UuOhOv9sbqJrYSea6+Hv4sNUO 
hO1lchQKBgQCKLEH7vWOX8 fkw+yKnmvAFoz5H3THUQw/WYsoCOVnWoY+vowcuuTTt 
cbW1VkrtEjJPuYeEPa5NI2kmsNUZGrKCpx/ 3Uq2JÉMVOpJZINIbiFM4ulcKqfI9ie 
hiVIFVVmxq-tdVmXBgXCknhYK1Mnt9b3BK6mDqerQjK1TKryqAJ20pQ-- 
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Domain certificate for example.net: 


MIIDITCCAr2gAwIBAgIJAJajhBdO74pUMAOGCSqGSIb3DQEBBOUAMHAXxXCZAJBgNV 
BAYTA1VTMRMwEQYDVOQIDApDYWxpzm9ybm1lhMREwDwYDVOQHDAhHTYW4gSm9zZTEO 
MAWwGAIUECgwFc2 1lwaXQxKTAnBgNVBASMIFNpcG10IFR1c30gQ2VydGlmaWNhdGUg 
QXVO0aG9yaXR5MCAXDTExMDIwNzE5MzIXxOVoYDzIxMTEwMTEOMTkzMjE5WjBbMQsw 
CQYDVQQGEwJVUZETMBEGA1VUECBMKO2F saWZvcm5pYTERMA8GA1UEBxMIU2FulEpv 
c2UxD JAMBgNVBAOTBXNpcG10MROWEGYDVOQDEwt leGFtcGx1Lm51dDCCASIwDOYJ 
KoZIhvcNAQEBBOADggEPADCCAQoCggEBAKOWx8gl1KbnGX2YEOXrbod2pbROfpkYW 
V7O/tIWHddl-tACLlqqNPKSmIqwAFbZ2uf78950kXhkgRJGw3BugftUJS7zDhqVqi 
dgPLMUPrdzpFazeh/AwBjcOwNBz/6tkUXrm7y/FwwzaCoKw-t*8Qm4Ibn2bE3bNqWlm 
iyKOXnYt4LGmy6J5e64hfQ3VqeO0ze5cfLKcpBbjF/TF75utbnH25zE0C/olb-*xlf 
dwyDjsHONN-AlZFrI2NdleVAuH6F2vx4ctwZUZzUJXyXezFmw5SRzhtWkbOiHOOER 
Ne7hCHLCv2Z26/GfluHirCsGtNKSQIC6k74MyD7D75nltnLVgJ7Oxt28CAwWEAAaOB 
hDCBgTAnBgNVHREEIDAeggtleGFtcGxlLm5ldIYPc21wOmV4YWlwbGUubmVOMAkG 
AIUdEWQCMAAwHQYDVROOBBYEFCITKpLjuKa/dPumVbeFXEWAURGEMB8GA1UdIwQY 
MBaAFJVFfl18r6mWYEpEE82PHaJpYFncnMAsGAl1UdDwQEAwIFA4DANBgkqhkiG9wO0B 
AQUFAAOCAQEAJry8LukecUvADUs5u/s6IymyqDLpeNvm94yrlIIk/eRW72Jtr9rf5 
6zFO0Pd/*NzDXRYPe99HQOgFGEKYndKIfnRUStJzIqiba2UszypDVRTQ6W9cH9e/1q 
FdCjjeoVkRvnGo91S8DkgWM4boNRUgZt YwP+I1ISHR+071T7tpOf4fKjYX+NxPe30r 
WzbLYXFDEiPndEgcxHc84HEeupit 7VBOm7 jxtF+XbaVGiLPGKCiYqdVSO8h2ZakRK 
8T3xL8Ecs4/rQn7PNPyEfS52R8hC70r66aAxZqLbKNpth/S23/hdeAyJ/NnFMW1J 
uq3kB5YAJSwMYAUXaQhB1BvxKzXqst zJHQ== 
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Private key for domain certificate for example.net: 


MITEoOwIBAAKCAQEAghbHyDUpuczZfZgQS5etuh3al1ltHR+mRhZXs7+OhYd12X4ATuWq 
o08pKYirAAVtna5/tL3k6ReGSBEkbDcG6B+101LVMOGpWqJ2A8sxQ+t 30kVrN6H8 
DAGNzTAOHP/q2RReubvL8XDDNoKgrD7xCbghufYTds2paWaLlo5edi3gsabLonl7 
riF9DdWp7TN71x8spykFuMX9MXvm6lucfbnMTOL-tjVv7HV93DIOOwfQ034DVkWs; 
Y12V5UCA4foXa/Hhy3Bl1TNQlfJd7MWbDlJHOGlaRvSIC7QREl17uEICSK/Znr8Z81i4 
eKsKwa00pJAgLqTvgzIPsPvmeW2ctWAns7G3bwIDAQABAOIBAHI jpV+B5YVITL59 
TUCrAJyKVLGlioQf/CygafjtZTVVa6v/aRn8Rkgb8XyrJ9sXvZVBlTqiUbdMAZ9I 
8faVSKLAWsj3thkfSojTMzU77x-IdCG6LxSzekAGqAIJ7SRL*iEzl/FmlWlgEYhl 
GIWILgHHO1n300eCy72dwmAV-2Hazn8eBggkWxMpOfblRC9pVhOFCo-tjyllHasjL 
oOBkH511bmZ4PUuUY072j2665gPm7i0nr25igef842JkbqAV8rAoN1Q26Y7tYLEw 
6QyLvOodebOrHZ8IEzahWAdmIPGCIUCFM7RmyInOatGAOdVEU3uYnkUQQVOi/JTx 
46CCMbECgYEA4c1Dv/IVz9pdwlo/OMaJ94zfeg7Pgn5DRXnNNMjCSSxVHSMINw1Ul 
BcYozs77vWbluXiXO2xQe9mGA2ss3-t*vNxBÜeu6EBQ/fK16cQQOH52nXdrVlsqnkN 
5B5elFKcZKPfNVWrgOBC6csDndTCcHp9STIKsxWkesLzC3Vz5UXZMsocCgYEAwNYV 
-SsCIQGLT8ZZfKyE2nHqRUFknKc/tWQJop5gnE4ws3Lql13SNyCUQr/sDYelxQDE3 
6COm197JcZ27jggDq7grigIxMznRxLMeG7bb7FfwPE/SKVO0H5uagEB7ktFl18xIJKt 
yOCKlulillQjToSs4uetHLRXKCDSEpRiSw7wRdkCgYEAkDKBXYa/nykYDUqpDi57 
1PbFkDD9G5x-*YVPTUOX6wUgpabFjEANHzVQOqoOdTRDTrYmY8Tdpx22WiS3SaB7WS 
hfcCtVewczM-ttlDZ9GnKoVQ761IaM6qC72j36sEXBUhPEa0722K8Z2DCxldsmEeJnN 
+MZKhxcGX19t IehJ31foyukCgYB9AUsS1PwAeTVX1 30rduyhUQ0 xOoNmMA4 91Euh8 
FpciPD2tlmzkyZWvjPeIXPwOWLglmMJZJeNeRPnpQcrR165zqXKzSj/wBePn12BM 
cTXLRp6vnPKhJgt+wno4eQ5hKzGKYbvlhHs5iCuDx+pD4swWwExpmW+Gdn2FXCYwsAF 
UCXJ4QKBgAKSrm8Y5xOhd8RAMg9JZLGUpP nmTKNU98f£3fUFnX7jZEZETasnn18vd 
65x04h58cohJJIkNxgeL6k31lc3MwOpzZrvsIha3ZzMEoJPCgwBa8zLzrR13YQin6yf 
+bAmf TDmhigpORB360ODY4BI1IkcwxKzQOn3XAt1rL7NRV5wHr2ejkY 


B.3. Certificate Chaining with a Non-Root CA 


Following is a certificate for a non-root CA in example.net. The 
certificate was signed by the root CA shown in Section 2.1. As 
indicated in Sections 4.2.1.9 and 4.2.1.3 [RFC5280], "cA" is set in 
Basic Constraints, and "keyCertSign" is set in Key Usage. This 
identifies the certificate holder as a signing authority. 


Version: 3 (0x2) 
Serial Number: 
96:a3:84:17:4e:ef:8a:52 
Signature Algorithm: shalWithRSAEncryption 
Issuer: C-US, ST-California, L=San Jose, O=sipit, 
OU-Sipit Test Certificate Authority 
Validity 
Not Before: Feb 7 20:21:13 2011 GMT 
Not After : Jan 14 20:21:13 2111 GMT 
Subject: C=US, ST-California, L=San Jose, O=sipit, 
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OU-Test CA for example.net, CN-example.net 
Subject Public Key Info: 
Public Key Algorithm: rsaEncryption 
RSA Public Key: (2048 bit) 

Modulus (2048 bit): 
00:d4:46:65:51:£8:84:1c:505:93:47:a5:15:14:006: 
ec:dc:2a:77:93:11:5e:75:14:d2:88:54:bd:16:50: 
dd:41:3f:7e:2a:e4:26:d5:a3:33:b0:5e:37:1d:e5: 
96:37:1lc:1lc:69:80:a4:ef:fd:22:78:d7:ce:d3:c3: 
de: 96:fb:87:30:88:bc:06:14:80:5d:f3:ab:d7: 64: 
3e:07:31:dc:97:c5:d6:19:26:bc:7d:05b:£8:de:5e: 
f9:0£:dc:9a:45:0£:28:8d:dd:£fa:15:56:4d5:35:17: 
28:90:2d2:f0:1£:806:95:95:42:06:20€c:47:38:53:ad: 
fd:0e:24:fd:a3:43:33:83:52:65:54:da:48:d8:dc: 
86:42:Ad5:26:ac:1d:52:54:08:52:e5:3f:4a:76:95: 
77:8d:c6:£2:33:£0:18:87:c8:fc:5b:54:5d:dd: 65: 
fl:S5c:f5:c8:f4:36:54:8a:b6:7b:6f:f8:55:f8:d8: 
d8:df:a9:7b:40:45:4c:92:0f:aa:b2:2c:al:a8: 64: 
d5:99:22:1e:28:78:a0:d8:e5:51:64:3f:03:14:a9: 
12:47:61:84:d6:b0:69:la:6b:a3:6e:d8:ca:ce:43: 
50:ad:57:96:2b:87:15:d9:c2:11:03:b0:82:d4: f0: 
80:bf:dd:44:f£4:£6:39:0a:2b:e3:4d:d3:f5:e7:aa: 
34:e5 

Exponent: 65537 (0x10001) 

X509v3 extensions: 
X509v3 Basic Constraints: 
CA: TRUE 
X509v3 Subject Key Identifier: 
72:70:CF:66:1E:23:A5:38:FC:6F:40:8F:86:8A: AF: EO: B9: 6F :E9:C3 
X509v3 Authority Key Identifier: 
95:45:7E:5F:2B:EA:65:98:12:91:04:F3:63:C7:68:9A:58:16:77:27 


X509v3 Key Usage: 
Certificate Sign 

Signature Algorithm: shalWithRSAEncryption 
70:73:c0:65:9c:2f:09:39:39:d6:a4:5b:95:e7:7b:43:34:b5: 
b9:b2:5d:76:eb:ef:87:e0:25:b6:68:ab:ee:f8:f7:85:c4:21: 
47:bb:6c:68:62:ff:f8:84:le:44:5a:30:4e:ce:97:91:cc:3d: 
43:4a:8b:b7:25:26:08:63:c6:71:4a:c1:94:35:81:66:de:23: 
9d:e3:37:de:31:80:ed:58:b7:07:a7:ea:87:d3:cc:da:1b: 62: 
cI:82:c2:17:e6:2d:20:e4:b2:69:14:cb:05:43:34:6f:b5:2c: 
60:Ad8:44:43:fI:e6:e9:3d:7c:54:a2:b9:d9:1le:7d:67:bb:3f: 
32:31:0d:c1:88:78:a8:67:39:f5:d2:3e:08:f7:38:84:a6:8£f: 
c2:3e:00:ce:5f:b4:c8:da:al:b5:2f:c2:89:60:a4:3a:2b:be: 
98:e0:44:34:af:ec:7£:73:26:£1:94:5b:39:09:b9:9f:93:c2: 
Id:7a:96:2f:82:66:c8:4d:f6:db:87:00:8e:bc:2a:b9:51:73: 
Gc:cc:ff:e5:31:25:b1:4a:d0:9a:a9:c3:65:35:21:89:76:3d: 
39:f8:84:42:a6:03:0e:b5:c9:2f:5d:18:bc:9d:b9:82:f6:83: 
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dd:2b:29:6c:8d:2c:8c:47:d4:7d:be:de:32:13:85:92:32:bc: 


61:62:6b:e5 


SIP Secure Call Flows 


April 2011 


Robert’s certificate was signed by the non-root CA in example.net: 


Version: 3 (0x2 


Serial 


Number: 


) 


96:a3:84:17:4e:ef:8a:53 
Signature Algorithm: 
C=US, ST-California, 


Issuer: 


OU-Test CA for example.net, 


shalWithRSAEncryption 
L-San Jose, 


CN-example.net 


Validity 
Not Before: 
Not After 
Subject: C=US, 
Subject Public 
Public Key 
RSA Public 


X509v3 extensions: 
X509v3 Subject Alternative Name: 
X509v3 
X509v3 


X509v3 


Jennings, 


Modulus 
00 
64 
ees 
10: 
3e: 
b4: 
7a: 
£2 
5 fs 
02 
a9: 
£4 
34 
36: 
Gf: 
9f: 
b6: 
f9: 


Feb 


Key: 


:d3 
720% 
41: 
9f: 


88 


Of: 
2d: 
:4b: 
3b: 
:e8 


03 


see? 
:e5: 
228: 
06: 
6e: 
8c: 


£5 


la: 
35% 
513 


23 


Exponent: 


:dc: 
66: 
4d: 
ed: 
:c4 
03: 
21 
26: 
41: 
> bb: 
:b4 
ba: 
:be: 
60: 
Dez 


77] 


7 20:21:13 2011 GMT 
Jan 14 20:21:13 2111 GMT 
ST-California, 
Key Info: 
Algorithm: 
(2048 bit) 
(2048 bit): 


14 


bl 
57 


:e4 
ZE; 
44: 
Of: 
36: 
50: 
29 
:4b: 
89: 
#29: 
f9: 
a8: 
06: 


TE 


ff 
21 


65537 


et: 


269: 
9f: 
sef: 
:D5: 
:ef: 
a0: 
:db: 
d4: 
9a: 
Zo 


48 


15 


01 


(0x10001) 


3: 
e9: 
66: 


Of: 
:a6: 
:bes 


rsaEncryption 


35 
00 


:28 


f1 


6b: 
JE 
£8: 
fb: 


bd: 


L=San Jose, 


71 


01 


70 


TER 


30: 
534 
6d: 
Geh: 
206% 


98: 


9b: 
SECH 
JÈL 
81: 
80: 
72: 


:09: 
06: 
5b: 
4b: 
63: 
2262 
:b9: 
99: 
:be: 
94: 
zgd? 
28: 
76: 
f4: 


c3 


63 


67 
74 


593 


URI:sip:robert@example.net, 
URI: pres: robert @example.net 


CA:FALS 


E 


Basic Constraints: 


Subject Key Identifier: 


ZÈ 
30: 
a5: 
9f: 


91 


54 


:e4: 
ETS 
45: 


a2 


8c: 
4c: 
le: 
ide: 
$695 
d0: 


0b: 
39: 
Od: 
8f: 
12.0": 
e7: 
:e8 
7e: 
4f: 
9e: 
:ad: 
Od: 
37: 
7a: 
50: 


£8 


95; 


O=sipit, 


O=sipit, 


14 


87 


:al 
42 


Of: 
eb: 
76: 
do: 
68: 
OY 
:dc: 


08: 
7e: 
ab: 


34: 
1534 
AER 
:0a: 
DEE 


9d: 
14: 
ec: 
9f: 
18: 
8e: 
d6: 
:0a: 
6b: 
01: 
07: 
:e2: 
3a: 
19: 


e2 


G 
16: 


97 


f4 


e3 


b2: 
4a: 
0e: 
f6: 
66: 
bc: 
34: 
:a8 


£3 
02 


CN-robert 


08 


da: 
:ba: 
0e: 
:8e: 
21: 


15 


92 


sar 
T3: 
db: 
9d: 
tff: 
dl: 
d9: 
81: 
ee: 
:bb 
“ZE 


SEL 
19: 
16: 
HERE 
3b: 
:a3: 
DI: 
lc: 
44: 
c3 
69: 
24: 
YE; 
lie: 
9d: 
:2b: 
ce: 


URI:im:robertüexample.net, 


A6:42:BD:62:0D: 6B: BF: EE: 67:D4:C7:BC:09:3F:0B:3A:12:AB:19:CE 


et al. 


Authority Key Identifier: 


Informational 


[Page 60] 


RFC 6216 SIP Secure Call Flows April 2011 


72:70:CF:66:1E:23:A5:38:FC:6F:40:8F:86:8A:AF: EO: B9:6F:E9:C3 


X509v3 Key Usage: 
Digital Signature, Non Repudiation, Key Encipherment 
X509v3 Extended Key Usage: 
E-mail Protection, 1.3.6.1.5.5.7.3.20 

Signature Algorithm: shalWithRSAEncryption 
25:99:ea:1a:1e:96:6d:4e:b1:9c:5a:43:77:ea:3a:a7:a1:b7: 
22:db:b9:d4:9a:le:17:f7:13:2e:b2:ca:80:dd:c9:a5:db: 61: 
41:c6:8b:65:ae:0e:fc:9a:46:77:16:e0:e2:3d:1d:20:3c:e5: 
d5:e0:b8:03:41:4f:e7:69:bf:e0:4c:dd:cc:c4:51:bl:da:2f: 
ad:58:el:ed:c6:5b:04:ea:le:af:9a:89:cd:be:60:3c:9a:30: 
51:7£:99:5a:6b:5c:8f:5a:d4:b8:ce:b5:8b:31:74:70:b3:cc: 
5c:04:90:d8:8d:b6:75:55:fb:cl:d8:e8:db:cf:3d:80:e4:8d: 
2f:7e:b9:2b:a2:9e:9f:le:6f:d0:4e:6e:f7:fl:a6:61:3b:9e: 
9b:4b:78:6b:84:37:ad: 93:19:0d:7£:46:5a:18:74:89:8b:a8: 
la:75:bf:db:df:25:43:4b:57:ab:al:19:2e:7c: 7b:b9:b5:50: 
ef:2c:1f:5c:18:8f£:6c:66:83:61:eb:25:a3:21:81:2c:61:3b: 
ee:8c:18:1a:89:9a:29:0d:5c:5b:38:f3:71:3d:61:f0:3f:80: 
33:90:f2:60:53:48:fb:7a:65:c9:5f:1f:a3:e8:75:42:42: f5: 
ad:db:60:29:c6:0f:3c:68:00:7a:2b:38:db:c7:17:b9:4e:d8: 
90:d8:52:bc 


Certificate for CA for example.net in PEM format: 


MIIDZZCCAregAwIBAgIJAJajhBdO74pSMAOGCSqGSTIb3DQEBBOUAMHAXxXCZAJBgNV 
BAYTA1VTMRMwEQYDVOQIDApDYWxpzm9ybm1lhMREwDwYDVOQHDAhHTYW4gSm9zZTEO 
MAWwGAIUECgwFc2lwaXOxKTAnBgNVBASMIFNpcGIOIFRIc3QgOQ2VydG1lmaWNhdGUg 
QOXVO0aG9yaXR5MCAXDTExMDIWwNzIwMjExMI1IoYDzIxMTEwMTEOMjAyMTEzWjB9MOsw 
CQYDVQQGEwJVUZETMBEGA1VUECBMKO2F saWZvcm5pYTERMA8GA1UEBxMIU2FulEpv 
c2UxD JAMBOQNVBAoTBXNpcG1OMSAwHgYDVOQLExXdUZXNOIENBIGZvciBleGFtcGx1 
Lm51dDEUMBIGAIUEAxMLZXhhbXBsZS5uZXQwggEi1MAOGCSqGSIb3DQEBAQUAA4TB 
DwAwggEKAoIBAQDURmVR+IQctZNHpRUUBuzcKneTEVS5IFNKIVLOWUN1BP34q5CbV 
ozOwX jCd5ZY3HBxpgKTv/SJ4187Tw96W+4cwiLwGFIBA86vXZD4HMAyXxdYZJrx9 
C/ jeXvkP3JÈpFDyiN3foVVtUIFyiA0vwf 1pWVQg4sRzhTrf0OJP2 jOZODUmVU2k jY 
3TZCISasHVJUCFLIPOp21XeNxvIz8BiHyPxbVF3dZfFc9cjONISKtntv+FX42Njf 
aXtARUySD6qyLKGoZNWZIh40ceKDY5VFkPwMUgRJHYYTWsGkaa6Nu2MrOQICtV5Yr 
hxXZwhEDsILU8IC/3UT09jkKK-*NNO/Xnq;jTlAgMBAAGjXTBbMAwGA1UdEwQFMAMB 
Af8wHQYDVROOBBYEFHJwz2YeI6GU4/G9S9Aj4aKr+C5b+nDMB8GA1IUdIwQYMBaAFJVF 
fl8r6mWYEpEE82PHaJpYFncnMAsGAl1UdDwOEAwICBDANBgkqhkiG9wOBAQUFAAOC 
AQEACHPAZZwvCTk51qRbled7QzSlubJdduvvh*Altmir7vj3hcQhR7tsaGL/-*IQe 
RFowTs6Xkcw9Q0qLtyUmCGPGCcUrBlDWBZt4jneM33jGA7Vi3B6fqh9PM2htiyYLC 
F-YtIOSyaRTLBUMOb7UsYNhEQ/nm6T18VKK52R59Z27s/MjENwYh4qGc59dI-*CPc4 
hKaPwj4Az1+0yNghtS/CiWCkOiu+mOBENK/s f3Mm8ZRbOQm5n5PCnXqWL4JmyE32 
24cAjrwquVFzbMz / 5TE1sUrQmgnDZTUhiXY90fiEQqYDDrXJL1OYvJ25gvaD3Ssp 
bIOSjEfUfb7eMhOFkjK8YWJr5Q-- 


Jennings, et al. Informational [Page 61] 


RFC 6216 SIP Secure Call Flows April 2011 


Private key for CA for example.net: 


MIIEpAIBAAKCAQEA1IEZIUÉfiEHLWTR6GUVFAbs3Cp3kxFedRTSiFS9F1DdOT9+KuOm 
laMzsFA43HeWWNxwcaYCk7/0ieNfO08PelvuHMIi8BhSAXfOr12Q-*BzHcl8XWGSa8 
fQv43175D9yaRQ80jd36FVbVNRCOgNL8H9aV1UIOLECAU639DiT900MzglJlVNpI 
2NyGQtUmrBl1SVAhS5T9KdpV3jcbyM/AYh8j8Wl1Rd3WXxXPXI9DZUirZ7b/hV-*NjY 
36170EVMkg-tqsiyhqGTVmSIeKHig20VRZD8DFKkSR2GElrBpGmujbtjKzkNOrVeW 
KAcV2cIRA7CCIPCAv91E9PY5CivjTdP156005QIDAQABAOIBADp/7/pIH7h9vcn3 
Z/hGNE5O0kaGBHuPrSh3yJG4a*O67XbzaRW213XzUaileHGixoY7duha9Txu4dbJc 
f2JijR4uAIs4aSv7NDdWO9VNw308NkWWLEnV288Eo2Tgqc8wXz/BleL9nCJWcH4Y 
Jw1rKKwKmTdOpVBCWcP1ITI9OUzduXQdZfBbrsL6+OZ+F3kbvUwYAVhhUuBS9sf4Xib 
5GA2CDLPm433giOS3yr9KigpcLvbhAhMiPTXJ6i65m9xGGCcjhxP/drOHOcNczRD 
yWOFCbaNRJUg9kEVu-tn3uGlaVfOnU7RqcblFXgO7ea7G*mfp3Cfm744kvFEXzO4Ak 
8WLW6gECgYEA91K9mKhMUeBl1-*xPJBA4AZa5QvrFc7nLt8ee7/aTNcyMIOl3uXyPDPj 
TNEfgaRobptmwd2HVtXj1Q54fE+pE+qS8dOORh2VFoWi91zI4C8WnM/6j5P+QiXY 
tcZDPF22bmsSW7uaQyaOhUfIMhzox1BbUHS5q5YrcA5DmmOtaxcIZ+IECgYEA3J07 
6DamIgyOeJO2GKHU/Hy8RvQZgauzCtmqmLQrWZeOmx9hORela71QU5F6Y3HQRCTD 
RDDdJua9Y8BJOWTkasbRgx jmHQ1f4pUdT6ycfWgISbcCNFTosgPH+/OZPEH4DK10O 
rblaUzHPuZdo2Q72KtSPMk+ikny21CZ9cm2mKmUCgYEAsGoX4fJ/HpDMzrKf 4gTG 
Co8bo jXZ+wbPVT/V£/OLtBwTCG3VrGpZG5YWo4n1RWpFEQmwuW9cnE+N2TJOXLO+ 
A47Vpiyv6r/OsSAMISCsWOw2ZtBFGw4v0qFR3W3 7Aa TUCgGFTnKbq+ jhOX/FQaH02c 
6KxxsM5 fvgoTjX7FVycp5TECgYA4TqgIWpHOcpq99Qv4sgunuM4v+dBj6fq9Q6qNf 
HEUgNc2BDCSNWx 7D4+rXmX7qgwMc2t3S7NImKLORRbGeg2RxvoFUjJ7y7100xmiuE 
BWN fogjS37HhV3aYONw/EzqeJOTOv1XFg1Utgb4p+VoaZHYyE1SGG8sTpjcXcwad7 
qD7L/QKBgQCeDLKx5T1d/EqwW8KNK5qD/51G/TOzu3MCD1zCjfs2BHMasv5RALd+ 
unMMANDEIPHOFs7fSmCfspN8Y74W15/k9WugpwQfST2Y8dSRVdPFplFRt8u25yX2 
mdRbU3vJSiAgPEEpKpBolXPxLOeLGvoTHFWSazqgmCP IKKxqOwL+O+w== 
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Robert’s certificate: 


MIIEJjCCAw6gAwIBAgIJAJajhBdO74pTMAOGCSqGSIb3DQEBBOUAMHOXCZAJBgNV 
BAYTAIVTMRMwEQYDVOOIEwpDYWxpZm9ybmlhMREwDwYDVOOHEwhTYW4gSm9zZTEO 
MAWwGAIUEChHMF'c2lwaXQOxIDAeBgNVBASTF1IRIC3QgQOEgZm9yIGV4YWIwbGUubmVO 
MRQwEgYDVOODEwtleGFtcGxlLm5ldDAgFwOxMTAyMDCyMDIXxXMTNaGA8yMTExMDEx 
NDIwMjExM1owVjELMAkGA1UEBhMCVVMXxEZzARBgNVBAgTCkNhbGlmb3JuaWExETAP 
BgNVBACTCFNhbiBKb3N1MQAwDAYDVQOKEwVzaXBpdDEPMAOGA1UEAxMGom9iZXJO 
MIIBIjANBgkqhkiG9wOBAQEFAAOCAQ8AMIIBCgKCAQEAO09wUaWtxCSwLD52VCMFk 
IGbvn5wwBjA5 6xQW2hnMOU2xz/hTW6UNduyXuhYOn+1XtfttS5+POJ8OFac+iMTk 
7zXRY5EgaBj0jjuODwM+oADWwybnV44hkqN6LSFESNsBuVTo3Nb jObPySyYPP9SZ 
Y+R+FAQYCXx£OOE26ZpwvvdPCGtK20QC6LtQOZiyYIEWefgEOncOpA7coFSjDzakKt 
qwf2/2n07Lp/S72bKIwNh+Jm0OSQ0O5Xe+ifHJdkw3NDq82Zw29ShgAS1c9B56FRk0 
gRzPGgZcD/mBZ9xQCeKo152fNW7/pqiAdGz4oQrzuyu2UYwhvAZyWaCVQtMCLM75 
IwIDAQABo4HNMIHKMFEGA1IUdEQRKMEiGFnNpcDpyb2JIcnRAZXhhbXBsZS5uZXSG 
FWltOnJvYmVydEBleGFtcGxlLm5ldIYXcHJlczpyb2JlcnRAZXhhbXBsZS5uZXQw 
COYDVROTBAIwWADAdBgNVHOAEFgQUpkK9Yglrvt5nl1Me8CT8LOhKrGcAwHwYDVRO j 
BBgwFoAUCnDPZh4jpTj8bO0CPhoqv4Llv6cMwCwYDVROPBAODAgXgMBOGA1UdJOOW 
MBQGCCSsGAQUFBwMEBggrBgEFBQCDFDANBgkqghkiG9wO0BAQUFAAOCAQEAJZnqGh6W 
bU6xnFpDd-*o6p6G3Itu5lJoeF/CcTLrLKgN3JpdthQcaLZa40/JpGdxbg4jOdIDzl 
leCAAOFP52m/A4EzdzMRRsdovrVjh7cZbBOoer5qUzb5gPJowUX-*ZWmtcjlrUuM61 
izFOcLPMXASQ2122dVX7wdjo2889gOSNL365K6Kenx5vOE5u9/CmYTuem0t4a4Q3 
rZMZDX9GWhhOiYuoGnW/2981Q0tXq6EZLnx7ubVQ7ywfXBiPbGaDYesloyGBLGE7 
7owYGomaKQ1lcWzjzcT1h8D+AM5DyYFNI+3plyV8foth1OQkLirdtgKcYPPGgAeis4 
28cXuU7YkNhSvA-- 
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Robert’s private key: 


MI TEowI BAAKCAQEA0 9wUaWt xCSwLD52VCMFkIGbvn5wwBjA56xQW2hnMQU2xz/hT 
W6UNduyXuhYOn+1XtfttS5+POJ8OFac+iMTk7zXRY5EgaBj0jjuODwM+oADWwybn 
V44hkqgN6LSFESNsBuVTo3Nb jObPySyYPP9SZY+R+FAqycxx£O0E26ZpwvvdPCGtK 
20QC6LtOZiyYlEWefgEOncOpA7coFSjDzaKtqwf2/2n07Lp/S72bKIwNh-*Jm0SQO 
5Xe+ifHJdkw3NDq82Zw29ShgAS1c9B56FRk OGRZPGgZcD/mBZ9xQCeKo152fNW7/ 
pqiAdGz4o00rzuyu2UYwhvAZyWdCVOtMCLM75 IwIDAQABAoIBAAv+Q3GMUYPRaHb 7 
ITH+EKr86MfCUb2n8T9rjbefCj8QJOa/CgkAGPkIf7ZbFWnYR8TXjOJRHEAUhW+zB 
4PphGwynoUjfqFP8RavfmVvYNSldnsrBYwtDO0oa4lmwDnBf7vec99Ui7KX5vj2HN 
r8NPR7et8a00xdFaY9G46WDkCOnkH8AqMMymY /Vu2KpHOf01hTpFLmxS7We-d3Uq 
mval5GUc8-«-EL079uphokchr4E0036Ce41uCnqQOfOUAKCXCMYK271G5uue620IXLE 
CqeevZPEn8eqWhSNGl1981CF15AEbOtApMcMwrfcbpnOMHQuyOHm2XVewgFOgQGLn 
UAO0i6NECgYEA9TrFg3Kuw1Vfi+kztX6IMjWO7YQgN443NtB/9+sXKoc01Iz6LoPbOT 
VHSVqHHpjicicBUyUa77Kr61HAv7AVOSs2FRHAD3M7wOVYGkT52*1204FH6EMUA42G 
ISAcsS4vCfHhYq1TOhC9T1bIYIXXxuBrpoOybIRkEaSALHNG6arAEgWccCgYEA3Sod 
gEcahQEnu5P8UY5 j 9yFaBRqVxdOKWnO2trkfLkyVgtvn7ES31EGojVHg23nr5TsK 
IpwFgBiQvEGUgV3dRO0Jc5sZTETOweWBLebC/CtZfnhBcCNx8jwX5m/CtTzMHuxVs 
VJIWPUDNn+K7+G8KIKO+Kp5QdOCxXptHRLKGPBCUCgYAVgCuIFL8B3VBdQfsIpKl1Lo 
TZEpak5dbydj7ZIIFIZpnUJyggP+tOnr87TTafliPOgjr5gTIVWsSL8BNTzeYrQSr 
iugW3P9EzXmhVFUsa3zORpNobIRaJwRljx0046m4137xWeUJe/JI9C590LQSwjlN 
2f-ntWPPm8GdrF6/SfH-LOKBgQCyDaf2kEf/cHCmiXuHxVUhrsA4kccTGofE75RDi 
hqNdyPZNhfFvu9srnTivnY2j5MJPGsksF-t*Qtvpk3lqySghkVt43HlT9nB/A5p5bb 
/ TImuZexQ*ua9k5UMKE10jDNDbICBFk/fFH26UWG7pPSkC/FhYVg9Q3uOvR7PBCAYy 
CUFN6QKBgBw2k5 SDvun4TIwNV4wxGEli9ia+i4lzg8pwJIDUxnOcDvIDGZAZCNtW9 
wPoR+ jvhK6V6X1mIOtqgqcYZO7pC3CJBEtAckHj2Ik+ZAEjQOMf+eH62Rcv6Sbozq0 
5dFCBZwzIe2IQomg3J8+OyILSs/uzFkjGjloJIrP+OtPKSrfR+/Y 


Appendix C. Message Dumps 


This section contains a base64-encoded, gzipped, compressed tar file 
of various Cryptographic Message Syntax (CMS) messages used in this 
document. Saving the data in a file foo.tgz.b64 then running a 
command like "openssl base64 -d -in foo.tgz.b64 | tar xfz -" would 
recover the CMS messages and allow them to be used as test vectors. 


-- BEGIN MESSAGE ARCHIVE -- 

HASIAIpaUEOCA-*ybeUATxx/7HCSCIHIpoqdSIQvFECu5tsDhAEDATOhCsQExTZ 
JBtIyGUSIEREREU8ilZRqVYERVHUCgKiUBWPlvusXCJeeIv3LfpCaRUpSF8f 
tIXH/JPdma3fTjYz8/n+fr8JT6LEKSVCCYQgTKCMd+YhKp/ OLAABEAgHb8Eki 
wp 98NHSIQACxIAhDBACGIRDCAiCBOCTqYAGdvG6HEKFWIQtsVrkKISD9zXVvt 
JdA8F++HzCy1lOr+BgD5oXVimUOOfHSITRMndUjUJjkYtRRigqwwb4BTpAjYNoj 
VIg4/37mxBwTgAUp2iNHyBFyBmEAAF24CkTKi3LVUKJOBO5YHJ9MggkaHAUi 
CxASgSvAc3kwgODgOBzu9zYXhVymULnCAImgfOAdUeO8Z2Yo4RMFXOmNJ2hqm 
zBk' 7quV+uZn28FbIJL+1C8QxAkH8h3aeTOLmokIiXXKIWSAgEHimPcYgYj#HO 
lrgMZYui49gsdpw/ky9mM33V2mOAwWTDdCpPQ6eFSugsuppOjYbZIraj9rZg 
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dLIzlkwg4bG/vSfTHh4 8HipXOWMIMWKVUI 40VE5KYaQU5TtgVaha5SQXI0Kp 
AxaRy8VCHqISyqRO8miekoRrmGOfliv5cocmZhCxClVItU2xqPbJMqkKlapw 
zHg5+sdnuXB1IMVI+ooh3JOkKATOoULAhRAwKMIINBForUujnRVRiGgilwhU814 
MrHrwD92p8EQoopRoAM/PmwcKolURWlffsPbN*2BwzW33rxfH79xkxbtOFAK 
UAXOS8qT8YXSSGcsVyjV9rXBpA8qFsvs/ozpz/TYRYpIUNdfFylHOUn58U6q 
UCMXKYUN92gNgFQILOqgirXeJOgR8sbYnrgpOcoxQoX1/AqgEYbc3KZ278AkIw5 
b2A0ISUn5 YUpx1A3Mx1zSFuIXxeDAYOAQ4NuI830dPsDxh8vwYDJmCztJd9r 
LwGmAnLQGDAyOAvRN7DQDOkGLODzhpPuJr80UaFAppAKEdAC6N1Qa2jSPRiR 
YvlkShQ0OA0waqgkx7mHTTjnihCrQHhjVUGJtggxvOSUxUqcKOQRUqoaDhtaFY 
jxhVlEwhVMXrGumkZ8-0ZDyYS//YQ9MPPcRguunoJ2NOVHQ7yoWrVxOAzsZi 
RsQC4fra-*ID-*26b6nduvt7rflKzYZQUngRPcselYuGo/vwK/OP3ECL31UgeT 
5wu-tdX-*cWmm/2bjU7NU50VKHeGmpK / cGM9cqT1D11U6qWM9q8sq61/f03247 
Icwy/tDPu53Wi8dePMXNftLfavBld8Eo/9kpe41EmjERI9+Wu45kWR6brjci 
VDg9+bX60IInp If Zh+7Mu2VCtCq+WG813T7EnZmvFFXOZRSCSmISSCuPqjatJ 
1+5dXwd7/5ilzHrzbirT+f6Syli/wNlrp2q4e0c4PZ7AeXfORtHFiXeGPoYt 
+2FPLktnKFYq6m2 j9o0smpHg+vv9Y j077iXoooaVBicOZ9ItDp3EWCKpVIJIpT 
iZU4BaqUd4QEaIP/AIEENOM/DAH4Lv7/HeU3pGMhbZ/9xzbn/LjgP815HokM 
IwCJhFAQMgEGuS1zHk/+SHV1C1h3hgEi2MhugA+QYBgEmoJe2QLpG3vVeA+1I 
UPAEPMBtwnt/JkdCp3pB/iyGlvehIgYl1WsPWeEDbRWUFiOjWEwKB6qTmSEAKH 
G£iB91oT5I+8bw7HX9HYeZaFJvO/g9R/2/0f 9Ef9D+Hhrvn/N+v/Vmdkal5A 
B6wOrXsBra8X//gS8U+4BC1J79+XKGITqgd3GT7y+VodExXOF G6HRgH+e/8fJgJd 
878z+P8CroDHhfFkMiSABDwC2Ir/T+gQ/59PQUEKDOaaTHYG1VviT/OF2CJe 
PFvjAdJpgXEMUWA8ncUmMCShOQzIWORniiUMmu8X4f8L8ESUC8E8MSsCDiBCR 
OL7+f£3Pr7ej/t2W6y/9vf/8/8HP+v9NPVS5eaR6TYVREWL£hu+11h9PEHI1Y17 
3jz7fs3BmbkOBuG3w2pqtwGq9cbhC60dH96zemP jG4apsSHkbVgcoUcehTFK 
OWy 7cOCpAU/puqGxdgMgZPODtBLNnvfvJ/vNw-tutn/rowmayYapSsrV8Dykr 
oeeNqsQnR8adKxop2bOKs3FLYdEZeealqUusqmMYP5nVzdYPybwytua2/eLE 
HIKtuBdqgepaMG+w9Fn8y8krfgOZDhjriIPcK2W385634htWhFRL3aEneT7xP2b 
u4blewyC5s1GzZ/Pt/LaHLkhZNaNd2YF9k604RuOKkWaQTtOVP 5UOGTKnAvB 
MxPUO5e9HvBypdFIe7tcIT/uSkuD8v/A/2/kfyP7USIPES9Xofx2VgBt8R/C 
k5rxn6it6uJ/J*A/SsaDFDJERPB8PpEIEFvhP9wh/Af5EB8gkD7hv8gXr5X7 
AIMZDdI1gQCbFaLVAtEgg+YXxWCFxPmz 6ABd5B3F OPA+8B8PEYF/iv//A9L+ 
FNHagm6DLZfGl1UGlvcQOVlcaiYpkc5eO0SwTyKYklfl1OSMBFupKYu-tBGJepnJ 
ugO1VTa6GBOtHAVdo6bhUe/hP0OzGoBSjuolZeP9XrMm7+knrDUIfaOajutiR+ 
1V3a4n2njLBOoePccHmXneaWvBeZ59noD3vlpzFMfBpaqZzd229hH1D1sCMOD 
o7vxgaEUfRl133svcUzD951YZcOPDjqzPej56ZblXwcnKhcJdgUOTVdhizi77 
bUENr48KjZ0gsN+jCslaBizgpe9Q7xylet+m11+dHXyROEVgrS800f1457vt 
tW/N3Q5gfpyvd9ku0U6j/7Vmh5GqICyaIApP8JwVysod4jd9p/skL/eTD49W 
SZ2KUAvU5iWxo75POZTx3bDM51I10g3fnw7O0KlDdWzJbl1DU3LNfd5GRYb/dB6 
a+y8dkzcwoTf f GNyxsvuUmM+OjgIQmUgawN jCKSPHBoHr 6GF39XrzBx9SKM6eD 
a4oSrqXTD71IKCoistLQOITIMeYfRj+XKOKK/oVeHiy2nwiITFQOZutH/DpQeqgc 
vbIj9dHIR+ZA35UuQs2ZJÉIlIvOnV+q7sweLwNN7g0irbvoHyN18PmT7tpV/GI 
rJudnr7/Lv531A6Atvl/uLn/D*DBLv53Av5rf08eAIJ8PAUPCAQAORX-*A4zuE 
/ xREO6i4hE/9fzaBzvJV- 7NC8P5MD5AhiobpLHocR8KOYOCcteAbkpWEwfWE / 
JU+L8P/xRATSyis+Hw8QBGSY3E7+P6HR/29uvR39/7ZM/3v9//JP/f8j2apD 
D£5/g3Rp 9K676TSPAKZVXpT5r4gANO1 jVwygpRhA8 4HZyWMAT fn fMMN+DwK0 
pxBog/94EoRv7v8TiV3x/87AfxKfCwoIJBIIKOABVOX4P 7F j+#E+GIJBETjXh 
Px3yBTIMLzydGtWw/w/mMD1ICjihKxKD6SdgSLzWHqm1 j88X+tI/7/2ACgfJv 


Jennings, et al. Informational [Page 65] 


RFC 6216 SIP Secure Call Flows April 2011 


5T+£CBIh1LEQgglwuiof57cJ/kADD jQKgufkOCxh0dJz jC41BMFgAcvKdjFmr 
LOziPSuQYdfIDmX9vIJ7ro5zN3koOb1nZXDiqzQj2PxgRPfvt3692MPesDw3 
HOmRFak32LoZXSW5mZVmmHEWzc6t9900ZeP9gYbHTscbvXB5Yuk6d7DnTupR 
ZzS97Jtkejg3IeTE3/yvh5Ko6cXzQpnFhIJ9SYbN5dIplpRA4F7337BfKy5vOI 
zDy7YUxd/zmPbLdcnxcOVVBa+lw1YOBGVC/r8WGZ5CdzcoQFugTS1IKP97Yfd 
t2TaztDc2oZRG848pK4SbVjCjb1sE jbbgDNGrCPKC/ZZ914Usqgo/bXj/+OUX 
PHUP 6r6calRTeHPOnKiHZy3STN8T7+wvs31XNpGZbuJJ+lwIYgGsMP1IIVUJ3 
sWn+UVD31ImNSwPnbj/Z7mvZ4ek1i49fPd4PGduPzY/cLyOeNLYOVYZLKAiTB 
K7aM74m3GMg/XX3D/RnboCgzWqWesPSOxb7COT7Dt2bOhYOr5C48vzDPpttsi 
gMka8temQZdYbY/tgqp8Vq0rvxIKvig7nF71/PmnMyyzd0mn6eVzNU+dvH2w4 
c8XBuLdNOYSMHBfhvHnjYjg78aylKLrrTOlyNl1gF-*PRFl11SrGZNnmU-*Wjk05 
G+saWzZdicn8BeVBe0g/IrbKKiVnCUFr2IltxryU+mccj+kgCvMfeHSVh9502 
ab 7u01UQ5f4O05wr9Q1XXhsfVDPUoM4ms31THcGaUbinanG12t/ervoY1R5Kr 
hOtLLdPDfYcrZxUnxkwetmuDXt7-3WXbl1V6S9L2mPfpaTl12-*Zxt31HGR5UNe 
GrSg8xWj7tNcsne/vbDVITToHJmT3+v2p1599bIm6Cfu3mzn8F4Ve2XiNp9J 
uum46AWJRNo1C3J9SyPzvlarHZv5+bPSH2LZ+A8IduV/OoP+40EkIoSHuDAB 
5PNhiNSK/gM7RP-*REAjFAxDCVPO9R2fFa7RflT/XAMIheEEfklbAPJMOfyRHT 
RV5qBssX4rAC4zg0elf*5/8r/9089irq/Q20ye8qef/lYGHqhSE33fW2XYq3 
y741iGN17M34p8t81v/80LXGI5uTBsmTX/9wqXxJgtgR8w5fwjlm6D/-tkuzO 
6Afb33grxmekZs4AqgHlT2s5Fx2gK/SaPTE/LOX-13S3eH2RPTx4v8InPrAkXL 
ylIk99TSw5dnJFzRseW4AsyNMyu5mv9EvOLLubvz9gtCXzwPzw8dfLbccjs/4Z 
Bc836zMt7fQUPR2x63T722WleTHhlx9WX3PLN1h2wTf3GLn705ndnuO0rDsk5 
f658fm2e-ttpVgWEvnA8cOOF8U2LX7XRAjH-*f8rjYwxY5Pr2nDDk-*cKKyxP16 
X90sit*xipDua*sYc8N3H/TzXvk57XUUPlpio55RgRXTilZfXJSaFGClpfdB 
S5DOTSuOD5hWuHzt3rP105bsKSR3Yz8mrz1hH2NpzbMy/gGXa jBNnf SE43YR 
3jvORg9iL6+snz6pwoPn/HV94cw+GG9j97uh9imOeWfqutI/HVS8+ZHS5wcVGI 
ChcpU+Eal7N2VAJt7f8Ggeb5HyIJALr4/3evUdgnod02jL3/+d9i/P/5K/hdP 
AqGutd8J9D8eoUAQ18jnAQJAIMC3ov/XlA7R/6iAyEXAMNOO /wsxhByRL8AQ 
BYKYIECAzmSDDKr2mMWQOGkhIJ3gAdGpQVF syZex/xvPhUEYBSGOS9C+ahBs 
5/xvM+vtmf 9tw3RXSOOfCK11/Q£8 jwozk+d/ozbz+2fzvIDz+B9M6Mr/dgb+ 
UOgIRERhCpcEESEuvrX9X1CH8B9PoghgLvRJ/lfEjqNr-*CI2k41ns4Ki2ZpI 
DVOUAtBpvgS6hgcxRNEgW+MnzZmi8voj8LOrmC4goyENhPoiS2+n/Xx/zv83N 
d+V///4YpK+5sX1Q7qgprG9+kHALvb+/jC9FWz3JLOJhz8bufOsYWvLZJEonyC 
onxfckRIwZiXgfOhedwnYyUrvzX7qzm93n+1dozqlplqG6uV6z33LdJKzkqYP 
XJmVbNpjl1sOoBxllEuvBI3PDCzIy3dZXWA808zwmWzddMGi4TsIK0Q690YnP 
fe4s80UflbszJt*a9mHln9LAx9Zeu9qrmHYT9LHjGEtOMXzYpKML5 6D jqwWww 
Ir5oQ/YavXqPIblrn7yknZzvWTEObhlra/-*le7utu017fGbLRYtEqxkT5h-40 
BYvZNt*ql1GT8sujc5Z29pwtOFW71f3RZwKDOvpbpC8fWeVTnWeM2XYl1YTOzXNv 
H9hlEP65IGTqdxYx6wV9Dpw6cfj92UUTM5MCkoyzd7LmbH8q32LdJxeufmUt 
sPcOcre44ul3qPbepldwzo061P+7TDoV+BykDp/YaZ/o0XV9tPouReO1AcX5N 
iGX8pMeM2iGeJC/KxOeVrAyG8V+bB1llitcPFqjQwb7Dj70Q1dUkbQorP 9 v EW 
2htNyt+6Ubbo7LJ4KGzrOXdr1GOrWYzDLpHwxutqG/a3dZ2G8€OBtNcrHNOJGU 
GJOcoYsxopOTH+5zCPR+s55IvcY/bH7MOLr+iSSh3m2L46196u+fWq3BRhVd 
OnfN502LPhkO/E3DgkqC7g1L7VNSdAYD50x2fKsPb3zn+/CM3K3ZGMOmW7tgz 
KbdrHEu-*pdxzwgRnTutflAOtvbloQNVAv8gZS/IZw3NPXPLTF11O0SZsyflKV 
Jj09cwhSOj5reG1B/iNJoMFKNWJa7rxtdXbhbOMk89Lc/7RvxzQMAgEARRkw 
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